System design in FPGA
in [FPGA]
|
Prev: Call for Papers: The 2010 International Conference on Wireless Networks (ICWN'10), USA, July 2010
Next: how to read bmp file in vhdl
From: rickman on 19 Feb 2010 17:04 On Feb 19, 5:50 am, jozamm <joz...(a)gmail.com> wrote: > Hi all, > > I am a budding FPGA designer and I am in the process of designing > first system. Until now I have partitioned my system into various > entities, each entity implementing a small part of the system. It is > also easier for implementation. However I have found myself in routing > a lot of signals from one entity to another which increases complexity > in a way. > > The other option is implement the system in a single entity and a > number of process. This would simplify matters because I would not > need to route lots signals between one entity and another. The > disadvantage is a lack of clarity. > > What is the best way for implementation? Any ideas and suggestions > would be welcome. > > Thanks very much, > > Regards, > > Joseph I see entities as being a unit I will want to test independently. Many designers don't test each entity, but I find that to be the most productive use of my time. I partition my entities to minimize the number of I/O while preserving a logical grouping of signaling. At the lowest level, there are times I will have an entity of only 20 lines or so. Other times a low level entity will have 400 lines of code. I don't like making such large entities, but there are times when it is just too awkward to partition a portion of a design. That may be a sign that I am not be thinking of the problem the right way, other times it may just be too hard to do better and I need to get on with it. The easy way to stitch your modules together is to use your tools testbench generator to create the boiler place code for you. You can then copy and paste much of the code into your higher level entity and just touch up the formatting. By testing your entities before integrating them minimizes the rework in higher level modules of keeping the stitching updated as the interfaces change. Rick
From: jozamm on 20 Feb 2010 04:44 On 19 Feb, 23:04, rickman <gnu...(a)gmail.com> wrote: > On Feb 19, 5:50 am, jozamm <joz...(a)gmail.com> wrote: > > > > > > > Hi all, > > > I am a budding FPGA designer and I am in the process of designing > > first system. Until now I have partitioned my system into various > > entities, each entity implementing a small part of the system. It is > > also easier for implementation. However I have found myself in routing > > a lot of signals from one entity to another which increases complexity > > in a way. > > > The other option is implement the system in a single entity and a > > number of process. This would simplify matters because I would not > > need to route lots signals between one entity and another. The > > disadvantage is a lack of clarity. > > > What is the best way for implementation? Any ideas and suggestions > > would be welcome. > > > Thanks very much, > > > Regards, > > > Joseph > > I see entities as being a unit I will want to test independently. > Many designers don't test each entity, but I find that to be the most > productive use of my time. I partition my entities to minimize the > number of I/O while preserving a logical grouping of signaling. At > the lowest level, there are times I will have an entity of only 20 > lines or so. Other times a low level entity will have 400 lines of > code. I don't like making such large entities, but there are times > when it is just too awkward to partition a portion of a design. That > may be a sign that I am not be thinking of the problem the right way, > other times it may just be too hard to do better and I need to get on > with it. > > The easy way to stitch your modules together is to use your tools > testbench generator to create the boiler place code for you. You can > then copy and paste much of the code into your higher level entity and > just touch up the formatting. By testing your entities before > integrating them minimizes the rework in higher level modules of > keeping the stitching updated as the interfaces change. > > Rick Hi all, Thanks very much for your ideas and suggestions. Someone pointed out using using records to transfer signals from one entity to another. While this is a good idea, will synthesis tools like Xilinx accept a record of STD_LOGIC or STD_LOGIC_VECTOR in the description of an entity? Thanks again, Regards, Joseph
From: Petter Gustad on 20 Feb 2010 11:24 Curt Johnson <curt.johnson(a)dicombox.net> writes: > Grouping signals into records can reduce the pain of routing signals > between entities. Or interfaces if you're using SystemVerilog. Interfaces can carry signals which run in both directions. VHDL records can only carry signals running in a single direction. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
From: Petter Gustad on 20 Feb 2010 11:24 jozamm <jozamm(a)gmail.com> writes: > entity to another. While this is a good idea, will synthesis tools > like Xilinx accept a record of STD_LOGIC or STD_LOGIC_VECTOR in the I don't know about xst, but it works in Quartus. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
From: rickman on 20 Feb 2010 20:56
On Feb 20, 4:44 am, jozamm <joz...(a)gmail.com> wrote: > On 19 Feb, 23:04, rickman <gnu...(a)gmail.com> wrote: > > > > > On Feb 19, 5:50 am, jozamm <joz...(a)gmail.com> wrote: > > > > Hi all, > > > > I am a budding FPGA designer and I am in the process of designing > > > first system. Until now I have partitioned my system into various > > > entities, each entity implementing a small part of the system. It is > > > also easier for implementation. However I have found myself in routing > > > a lot of signals from one entity to another which increases complexity > > > in a way. > > > > The other option is implement the system in a single entity and a > > > number of process. This would simplify matters because I would not > > > need to route lots signals between one entity and another. The > > > disadvantage is a lack of clarity. > > > > What is the best way for implementation? Any ideas and suggestions > > > would be welcome. > > > > Thanks very much, > > > > Regards, > > > > Joseph > > > I see entities as being a unit I will want to test independently. > > Many designers don't test each entity, but I find that to be the most > > productive use of my time. I partition my entities to minimize the > > number of I/O while preserving a logical grouping of signaling. At > > the lowest level, there are times I will have an entity of only 20 > > lines or so. Other times a low level entity will have 400 lines of > > code. I don't like making such large entities, but there are times > > when it is just too awkward to partition a portion of a design. That > > may be a sign that I am not be thinking of the problem the right way, > > other times it may just be too hard to do better and I need to get on > > with it. > > > The easy way to stitch your modules together is to use your tools > > testbench generator to create the boiler place code for you. You can > > then copy and paste much of the code into your higher level entity and > > just touch up the formatting. By testing your entities before > > integrating them minimizes the rework in higher level modules of > > keeping the stitching updated as the interfaces change. > > > Rick > > Hi all, > > Thanks very much for your ideas and suggestions. > > Someone pointed out using using records to transfer signals from one > entity to another. While this is a good idea, will synthesis tools > like Xilinx accept a record of STD_LOGIC or STD_LOGIC_VECTOR in the > description of an entity? > > Thanks again, > > Regards, > > Joseph Is a record really a solution? You then have to declare the record which is as much work as entering the entity port list and you have to do a lot of typing to use the record. Why not try a -small- example to see if that really suits you. then you can experiment to verify that it all works like you want it to. Rick |