System design in FPGA

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

>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
>

Part of the "art" of system design is structuring and organizing the
hierarchy in a near-optimal way. Don't expect to get it right the first
time that you do it. Do aspire to get better with subsequent projects.

HTH!
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

RCIngham 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
>>
> 
> Part of the "art" of system design is structuring and organizing the
> hierarchy in a near-optimal way. Don't expect to get it right the first
> time that you do it. Do aspire to get better with subsequent projects.
> 
> HTH!
> 	   
> 					
> ---------------------------------------		
> Posted through http://www.FPGARelated.com
Hi,

the one-entity option seems like a step in the wrong direction. Try to 
have a look at your design again, see if you can identify data paths and 
controls signals. Drawing sketches on a piece of paper usually helps.

jozamm 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

Grouping signals into records can reduce the pain of routing signals 
between entities.

Curt

jozamm wrote:

> 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.

I like big modules/entities because HDLs give me leverage
inside the box, but little leverage wiring boxes together.

If all else is equal,
Architectures that need the same signal   want to be merged.
Processes     that need the same variable want to be merged.

For me, the modules/entity size is limited by the unit test.

 -- Mike Treseler

On Feb 19, 5:50=A0am, jozamm <joz...@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 =A0entity 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

On 19 Feb, 23:04, rickman <gnu...@gmail.com> wrote:
> On Feb 19, 5:50=A0am, jozamm <joz...@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 =A0entity 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. =A0I partition my entities to minimize the
> number of I/O while preserving a logical grouping of signaling. =A0At
> the lowest level, there are times I will have an entity of only 20
> lines or so. =A0Other times a low level entity will have 400 lines of
> code. =A0I don't like making such large entities, but there are times
> when it is just too awkward to partition a portion of a design. =A0That
> 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. =A0You can
> then copy and paste much of the code into your higher level entity and
> just touch up the formatting. =A0By 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

jozamm <jozamm@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?

Curt Johnson <curt.johnson@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?

On Feb 20, 4:44=A0am, jozamm <joz...@gmail.com> wrote:
> On 19 Feb, 23:04, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Feb 19, 5:50=A0am, jozamm <joz...@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 routin=
g
> > > a lot of signals from one entity to another which increases complexit=
y
> > > 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 =A0entity 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. =A0I partition my entities to minimize the
> > number of I/O while preserving a logical grouping of signaling. =A0At
> > the lowest level, there are times I will have an entity of only 20
> > lines or so. =A0Other times a low level entity will have 400 lines of
> > code. =A0I don't like making such large entities, but there are times
> > when it is just too awkward to partition a portion of a design. =A0That
> > 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. =A0You can
> > then copy and paste much of the code into your higher level entity and
> > just touch up the formatting. =A0By 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