Moving things to RAM (LUTs)
Moving things to RAM (LUTs)
This is an example of making a counter and a flip-flop from the ram bloks. You just need to generate an appropriate look up table. And I want to ask, if this will work faster/need less memory?
- Attachments
-
- Counter_From_RAM.CircuitProject
- (6.97 KiB) Downloaded 1095 times
Re: Moving things to RAM (LUTs)
The trickiest thing I've got until now!)
- Attachments
-
- SR_From_ROM.CircuitProject
- (5.43 KiB) Downloaded 1158 times
Re: Moving things to RAM (LUTs)
Yes this will work faster. To check this you can run your circuit on maximum speed and observe real frequency.
In the attachment I’ve created two test circuits one is using your counter the other is regular counter. You can switch to ROM Test and Regular Test, run them and see the actual frequency of execution.
Of course didactically it doesn’t make sense as it hard to imagine anybody implementing counter in such way in real life.
In the attachment I’ve created two test circuits one is using your counter the other is regular counter. You can switch to ROM Test and Regular Test, run them and see the actual frequency of execution.
Of course didactically it doesn’t make sense as it hard to imagine anybody implementing counter in such way in real life.
- Attachments
-
- Counter_RAV_via_Normal.CircuitProject
- (61.97 KiB) Downloaded 1144 times
Re: Moving things to RAM (LUTs)
Ok, I didn't thought about such a way to test it) While I have made such tests in other programming languages.
I think it does have sense if you are working on the higher level and it doesn't matter how the lower level blocks are built. Not only counters can be implemented in such a way, but more complex logic. Also, you saw people making a vary complex circuits with this program, even MCUs, so they can speed it up, changing to this. Ofcourse, not in real life. But in real life, when you work on FPGA, for example, you choose predefined blocks. You don't think how this blocks are built. You may have an entire DDR controller as a single "black box". Also, FPGAs work on LUT's and multiplexers. When you want a XOR gate, you wil get a ROM working like a XOR gate.If your logic is more complex and you don't have such a gates, you will cascade the gates, but maybe, at the and you will get a simple LUT after a software optimization. More over, you can get out of LUTs on FPGA, but if you still have a RAM, you can move some of your logic to RAM.
I think it does have sense if you are working on the higher level and it doesn't matter how the lower level blocks are built. Not only counters can be implemented in such a way, but more complex logic. Also, you saw people making a vary complex circuits with this program, even MCUs, so they can speed it up, changing to this. Ofcourse, not in real life. But in real life, when you work on FPGA, for example, you choose predefined blocks. You don't think how this blocks are built. You may have an entire DDR controller as a single "black box". Also, FPGAs work on LUT's and multiplexers. When you want a XOR gate, you wil get a ROM working like a XOR gate.If your logic is more complex and you don't have such a gates, you will cascade the gates, but maybe, at the and you will get a simple LUT after a software optimization. More over, you can get out of LUTs on FPGA, but if you still have a RAM, you can move some of your logic to RAM.
RAM Flip-Flop problem
The problem is explained inside.
- Attachments
-
- D_problem.CircuitProject
- (54.72 KiB) Downloaded 1106 times
Re: Moving things to RAM (LUTs)
This is because race conditions in your circuit. If you add some delay it works just as expected.
- Attachments
-
- D_problem_fixed.CircuitProject
- (74.92 KiB) Downloaded 1185 times
Re: Moving things to RAM (LUTs)
Thanks! I just thought, that RAM block have a built in D latch that will behave like a real D latch.
Re: Moving things to RAM (LUTs)
Yes you are right the memory block has mechanism very similar to D latch. Namely it writing its data when write signal is changing. But you have more than one memory blocks chained together. So it is possible that two will be flipping their state in the same clock cycle. So having two inverters makes sure you have enough delay to prevent it happening in the same clock cycle.