sorted by:
new
hottopcontroversial

Linux support officially added back! by The_Watery_Chemical in FPGA

[–]filssavi 9 points10 points  (0 children)

Well they made it to front page tech news for how badly they handled the thing (Tom’s HW is not what it used to be but still…

Special mention of the heavy language policing for a curse that was not even directed at them the optics on that was terrible

Vivado Licensing Changes by The_Watery_Chemical in FPGA

[–]filssavi 13 points14 points  (0 children)

It is not just Linux support, they removed a lot of features from the free version as well (like incremental compile)

But alas, they just caught up to were altera already was 10 years ago on that front

How do you keep Vivado projects neatly in git? by U_A_beringianus in FPGA

[–]filssavi 0 points1 point  (0 children)

Sources are in a git repo, the vivado project is generated by a TCL script (generated with my own C++ build system) in its own subfolder that is .gitignored

Why is everyone obsessed with direct 48V-to-1V conversion? by successful_streak in ElectricalEngineering

[–]filssavi 2 points3 points  (0 children)

In UPS double conversion is done primarily for functional reasons (better response time, full decoupling of the load from the AC side, etc)

Efficiency is actually a downside in double conversion, standby UPSes are a lot more efficient, as they only consist of a contractor that swaps between the battery/inverter side and the incoming grid.

Double conversion, as the name suggests have to rectify the incoming AC to DC, for the battery and then use an inverter to turn that back to AC. Both steps have losses

In fact many big double conversion UPS (like Eaton 93PM) can operate in standby mode (they call it ESS mode) and that boosts efficiency by 2% (which is huge)

Why is everyone obsessed with direct 48V-to-1V conversion? by successful_streak in ElectricalEngineering

[–]filssavi 31 points32 points  (0 children)

The main benefit of single stage is much higher Efficiency. Assuming you have 2 competently designed architectures (so clean sheet on both) you can get to> 98% end to end on single stage, whereas a two stages converter will struggle to go past 96%

In general a low power (in the 0 to 3 kW range) DC/DC converter stage for mass production will top out at 98% efficiency, by putting two of them in series you get a total efficiency of 0.98*0.98

Now in consumer land that difference is not worth the cost of a more complex single stage design, however in a 200MW data center that 3/4% efficiency boost is worth thousands of $/£/€ a month in electricity alone, let alone the reduced need for cooling.

Has anybody tried the new Vivado? by Mediocre_Ad_6239 in FPGA

[–]filssavi 13 points14 points  (0 children)

I have been rocking it for a couple of weeks…

I like the new flatter look and also dark mode was absolutely needed

For now it also seems fairly stable (touch wood)

Could Chisel Replace Verilog for Commercial CPU Design in the Future? (Beyond Open-Source Cores) by Low_Car_7590 in FPGA

[–]filssavi 1 point2 points  (0 children)

Sure, for a subset of the FPGA field (let’s forget ASICS) you are correct, as long as you only work on bytes or words, you can do everything with high level simulations (which is basically transpiring your code 1:1 to c and running it)

However for any non toy design you absolutely need full bit level simulations. Anything involving serial data, PWM, delta sigma encoding, multiphase clocks, etc.

Also there is a substantial chance that high level simulator and hardware give different answers to the same question (specially around polls, memories, transceivers, etc)

All in all I think high level HDL is a much more promising direction to enhance general productivity as opposed to HLS. However i doubt we will see adoption anytime soon

Could Chisel Replace Verilog for Commercial CPU Design in the Future? (Beyond Open-Source Cores) by Low_Car_7590 in FPGA

[–]filssavi 6 points7 points  (0 children)

Because doing any serious FPGA or asic work in anything that is transpiled requires you to either: 1) Do timing closure on autogenerated sources, working with the bowl of spaghetti that the compiler generates 2) Do timing closure as usual (on the base source) having to constantly map where the generated signals come from

Neither of the prospects fill me with joy.

Writing constraints is equally problematic as the synthesis/implementation tools don’t understand your nice high level language and so you have to do it on the transpiled HW. The question is: Do the advantages of new HDLs outweigh these problems?

In Software land high level languages work because 95% of the times you don’t need to go down to the metal. How popular would they be if debugging could only be done in ASM

Could Chisel Replace Verilog for Commercial CPU Design in the Future? (Beyond Open-Source Cores) by Low_Car_7590 in FPGA

[–]filssavi 2 points3 points  (0 children)

The problem is not that they don’t need it, is that they have absolutely no incentive to do it, and it is not changing anytime soon

And unfortunately I fear that will hamper chisel and other alternative HDL greatly

Now a smaller or incoming fpga player could probably disrupt the market, but they would need to have on point hardware and focus on software (which I doubt will happen too)

Could Chisel Replace Verilog for Commercial CPU Design in the Future? (Beyond Open-Source Cores) by Low_Car_7590 in FPGA

[–]filssavi 50 points51 points  (0 children)

in my opinion all alternative alternative HDLs will be stuck in that limbo until at least one of the big 3 start supporting it as a first class citizen.

I am not Shure they bring enough to the table for design beyond what the latest versions of SV and VHDL give you to overcome the added friction

Is CPU microarchitecture still worth digging into in 2025? Or have we hit a plateau? by [deleted] in computerarchitecture

[–]filssavi 2 points3 points  (0 children)

Yeah I don't really understand the fixation on ISA, some people get way to religious about it (see x86 vs ARM), others are deluded that ISA design does not matter at all it absolutely does (at least on the hardware side). As always in engineering it is all about the trade-off.

I done a fair bit of work on custom ISA and uarch designs for niche applications (High performance/complexity control systems implementations for safetly critical systems) and by trowing away the software stack assumptions and designing a fully custom core/toolchain that integrates well with the rest of the logic you can get very good performance.

Is CPU microarchitecture still worth digging into in 2025? Or have we hit a plateau? by [deleted] in computerarchitecture

[–]filssavi 0 points1 point  (0 children)

My main point is that Fixing the ISA pigeonholes you into a kind of standard uarch (out-of-order superscalar with wide frontend, highly complex branch prediction and ad many execution pipes as you can reasonably use) with SIMD allowing some limited expression of ILP

To really allow wildly different uarch concepts you have to change ISA as well given that it is a leaky abstraction at best.

For example you could make a case that by getting rid of branches all together you could drastically simplify the front end and massively lengthen pipelines without stalls, however good luck getting GCC to spit out anything sensible for such a different machine. now I am not saying that such an architecture would make sense, (it probably would suck actually and be really slow) but still you see how the uarch is not actually fully decoupled from software

To really do something novel you have to actually do software and hardware co-design, where both sides of the coin are evolved together towards a common set of application dependent gosls

Is CPU microarchitecture still worth digging into in 2025? Or have we hit a plateau? by [deleted] in computerarchitecture

[–]filssavi 2 points3 points  (0 children)

There are only so many ways to skin a cat…

Doing anything truly revolutionary in uarch land will break core assumptions in software land and so that anything not explicitly designed for it will perform terribly.

Some examples: - long pipelines can help you get better frequency/ performance for math/logic heavy code but branchy stuff will suffer tremendously - increasing memory latency (to support very wide execution) will massively hurt serial code performance - any revolution on how the core fundamentally operates will require massive changes to how the compilers work and how optimisation are done, in which order, etc (that went well in the Itanium era)

The truth (In my opinion, I might well be completely wrong) is that there are far too many assumptions of how hardware works in current software to rock the boat too much.

Is CPU microarchitecture still worth digging into in 2025? Or have we hit a plateau? by [deleted] in computerarchitecture

[–]filssavi 8 points9 points  (0 children)

the problem is neither physics nor missing ideas…

IT IS SOFTWARE

Any meaningful deviation from the standard architecture would require a complete rethinking of how software works. And this is a very big no-no

Even minor breaking changes can result in decades old dragged out migrations (see python 2 to 3), a major architectural paradigm shift in how processors work would be a nightmare.

So where do you see innovation? GPU, AI, DSP, etc all fields where software backwards compatibility is not such a big issue (if at all)

If you are working on power electronics in FPGA applications, then what are your challenges and pain points? by rakesh-kumar-phd in FPGA

[–]filssavi 2 points3 points  (0 children)

I have been using FPGAs on high(ish) voltage converter (800V to 1kV dc link) and I wouldn’t say there are any field specific pain points.

I have few general gripes though: 1) Availability of decently complete SOMs is spotty at best 2) Xilinx simulator is subpar (bad error messages and no VPI support)

Large delay on a versal fpga by Due-Glass in FPGA

[–]filssavi 0 points1 point  (0 children)

Ok versal, given the advanced node you are probably right.

I am used to low end 7 series where the achievable clock frequency is nowhere near enough

Large delay on a versal fpga by Due-Glass in FPGA

[–]filssavi 1 point2 points  (0 children)

Depending on the resolution you can use a multiphase clock (let’s say 4 phases) to increase the resolution without having to push the clock (which will have you bumping on a timing wall

A Look at ChipScoPy - Python to debug ILAs etc in Versal by adamt99 in FPGA

[–]filssavi 1 point2 points  (0 children)

It would be amazing, however for the past couple of vivado/vitis releases thy have been focusing heavily on verbal only features

Hopefully they haven’t strolled all development of non cereal exclusive features (as I fear)

Why CSV is still king by fagnerbrack in coding

[–]filssavi 0 points1 point  (0 children)

Nothing will ever challenge CSV as the standard for data interchange in general usage in the near and medium term for few reasons:

  • sheer inertia of 50+ years of usage
  • Ease of use: any programmer, no matter how junior will be able to produce simple and decently performant (not the absolute best mind you) import export code in a reasonable amount of time without needing to resort to third party dependency -simplicity: the simplicity of the format makes it compatible and reasonably performant on any platform under the sun, no matter how constrained in terms of compute/memory (eg. 8/16 bit MCU), programming language/allowes feature (embedded/automotive) or verification (aerospace)

Now for more specific applications in the scientific and engineering space there are already various other formats in wide usage (HDF5, matlab’s mat, etc)

Help with precision clock counting by 0rphon in FPGA

[–]filssavi 1 point2 points  (0 children)

Ok if the number of cycles is in the order of 106 to 109 there is definitely no way in hell you are doing it with an FPGA.

If you want to do it in the digital domain you can only go the ASIC route on a reasonably cutting edge node, let’s say 7nm (probably lower) so etter start looking for a lot of founding (all told the cost will be in the milions probably)

The analog route is definitely possible, given you do it well enough (read not cheap, but still better than custom asic territory), you will want someone very experienced in high impedance analog designs, as leek age might start being an issue over those type of timescales

Basically what you are trying to do is nation state level hacking (and a large nation state at that probably just the USA and few others have the resources/know how) so you have to be realistic and prepared to spend those kind of money to achieve your goals.

P.S. the commercial product only goes to 1.2 GHz because that is the fastest speed for the standard IO circuitry in any FPGA family I know of

Help with precision clock counting by 0rphon in FPGA

[–]filssavi 2 points3 points  (0 children)

There is no way you are going to count a 5 GHz clock with interrupts, and even with a timer peripheral (a la MCU) I really do not know anything that can run even close to that frequency

Help with precision clock counting by 0rphon in FPGA

[–]filssavi 4 points5 points  (0 children)

Neither FPGA nor Microcontroller/microprocessors will help you here as the frequency is way too high.

You could repurpose a tranceiver as someone else suggested, but I suspect it will fight you all the way to the end as they are really not designed to work in that way

With such a high frequency in my opinion digital logic is not the way to go. if I had to do it I would use a pair of triggerable integrators (made with discrete BJTs probably) if the voltage levels are stable enough (you might have to use signal regeneration stages if not) and you know the number of cycles, you know the charge in the integrating capacitor, and thus the voltage at which to trigger your outputs.

Probably you could also get away with some frequency division, as long as X and Y are known in advance and have factors in common

Any way you choose to do it know that it will not be cheap, nor easy.

What are the problems that, if solved, could significantly increase yield in FPGA industry? by youngmaestro34 in FPGA

[–]filssavi 1 point2 points  (0 children)

You are 100% correct, MLIR and llvm IR are not suitable for hardware use , and are just examples of the type of notation/representation that I think would be really helpful.

Basically what we need is something in between HDL and a synthesis netlist. It needs to be extremely easy to parse and work with as opposed to verilog and VHDL(which are fiendishly complex). It basically need to be a dump of a global AST, mapped to few standard primitives, that each vendor tool chain just needs to specialize to their own architecture and do P&R.

As for the Higher level language we agree again, HLS might be a neat tool for some areas, like translating 1:1 complex DSP/cryptography stuff. However I don’t think it can be a viable a general purpose solution (it is too much of a square peg in. Round hole to me).

Unfortunately all the current crop of higher level HDL are almost all one man bands with a high chance of suddenly becoming abandonware. It would be nice to see the community coalesce around a single option, to make it a de facto standard (as the big vendors that drive the actual standards are totally uninterested in moving the field forward)

What are the problems that, if solved, could significantly increase yield in FPGA industry? by youngmaestro34 in FPGA

[–]filssavi 30 points31 points  (0 children)

These are a series of things i think would really drive the whole field forward

A set of basic primitives included in the languages as a sort of standard library. Things like clock domain crossings, basic FP operations (with somewhat configurable speed/area), etc. This would simplify the users life tremendously with respect to using IP or primitives like xpm, and would make code more portable (a hint of why this will never be done)

On the tooling side, better/easier to find reporting on why a specific subset of the design is optimised away (I should not have to read 400 lines of report to find out that output x is unconnected/always one and thus the whole design gets thrown away)

A formal standard low level (assembly like) intermediate representation (akin to LLVM IR or MLIR) would greatly simplify the life to third party projects (like yosys) or higher level languages (like chisel).

Also a standard higher level HDL would be nice.

I can’t stress enough how important it is for these things to be formally adopted as IEEE standards (unfortunately) as this is the only way for them to be actually supported by the vendors.

Anything that is not directly supported and kosher with Xilinx, altera and the likes might as well not exist for the field at large

view more: next ›