5 ms·
That's still an impartial model because each layer of abstraction can introduce path delay and resource usage. Functional programming doesn't encapsulate inter
by vvanders 9y ago
That's still an impartial model because each layer of abstraction can introduce path delay and resource usage.
Functional programming doesn't encapsulate interfacing across different clock domains or one hot vs binary state representation. Trying to bring those abstraction models to HDL you'll find a significant impedance mismatch.
- pjmlp 9y agoTrue, still it is easier than trying to think in imperative programming when doing FPGA programming. There are quite a few books using LP and FP for modelling of digital circuits. You can also introduce signal propagation modeling on them.
- vvanders 9y agoI think you're missing my point ;). You shouldn't be trying to think in imperative or functional programming because fundamentally FPGAs/HDL isn't programming. You should be thinking in terms of state machines, pipelines, routing, delay & setup+hold constraints. HDLs are just a high-powered blueprint languages. At the end of the day you're still just laying out physical blocks.
- pjmlp 9y agoAnd you missed mine, as I mentioned that we had electronic lectures. I am not talking out of thin air and wild guesses how things should be, rather about my personal experience how we learned digital circuit design and how later, already with that skill, we applied the ideas to FP. That was the goal of my initial comment, Hardware Design Ideas -> Help understating FP function combinations as if they were ICs, not how to design hardware from FP concepts.
- vvanders 9y agoDidn't miss it, just don't think they're equivalent. I appreciate functional programming and block diagrams/black box design are great tools for that space. However they don't capture the nuance of circuit design that goes into FPGA development. You can't capture pipeline depth, SRAM usage, thermal envelope/clock gating that have significant real world impacts on your design.
- deleted 9y ago[deleted]
- thewizardofaus 9y agoI found this discussion interesting to read. It appears it's comp sci FPGA knowledge vs Electrical Engineering FPGA knowledge. Not so much knowledge but how to think about an FPGA as a whole.
- gpderetta 9y agoSate machines and pipelines are very much about programming though.
- asimpletune 9y agoHow does the FPGA “non-code” get around the same problems?
- vvanders 9y agoLots and lots of simulation :). Part of it too is that you actually have a different set of problems. Let's say you build and abstract "Foo" block. In programming land you only pay for that block when your branch that selects it runs. Each line of code that references it just is the cost of a single opcode/asm call. In FPGA/ASIC land each time you reference that block you're instantiating a physical copy of the block. So if your block takes 8-bits of SRAM and you have 300 references(or parent blocks that fan out to 300 references) you're now paying 2.4kB of SRAM from a fixed pool that's usually only a few mB. Ditto switching logic, one of the fun parts of FPGA bring-up is they can have large in-rush currents of many amps as all the LUTs get flipped to their programmed state. You also have power(and usually thermal that's tied together) budgets driven by how much switching logic you run per-cycle. It really has a lot more in common with more traditional engineering domains where planning, simulation and strong math models are the standard tools.