System design in FPGA

jozamm
Guest

Fri Feb 19, 2010 12:50 pm

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

RCIngham
Guest

Fri Feb 19, 2010 12:50 pm

Quote:

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 th
hierarchy in a near-optimal way. Don't expect to get it right the firs
time that you do it. Do aspire to get better with subsequent projects.

HTH!

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

Magne Munkejord
Guest

Fri Feb 19, 2010 1:43 pm

RCIngham wrote:

Quote:

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.

Curt Johnson
Guest

Fri Feb 19, 2010 4:37 pm

jozamm wrote:

Quote:

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

Mike Treseler
Guest

Fri Feb 19, 2010 9:29 pm

jozamm wrote:

Quote:

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

rickman
Guest

Sat Feb 20, 2010 12:04 am

On Feb 19, 5:50 am, jozamm <joz...@gmail.com> wrote:

Quote:

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

jozamm
Guest

Sat Feb 20, 2010 11:44 am

On 19 Feb, 23:04, rickman <gnu...@gmail.com> wrote:

Quote:

On Feb 19, 5:50 am, 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 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

Petter Gustad
Guest

Sat Feb 20, 2010 5:24 pm

Curt Johnson <curt.johnson_at_dicombox.net> writes:

Quote:

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?

Petter Gustad
Guest

Sat Feb 20, 2010 5:24 pm

jozamm <jozamm_at_gmail.com> writes:

Quote:

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?

rickman
Guest

Sun Feb 21, 2010 3:33 am

On Feb 20, 4:44 am, jozamm <joz...@gmail.com> wrote:

Quote:

On 19 Feb, 23:04, rickman <gnu...@gmail.com> wrote:

On Feb 19, 5:50 am, 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 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

Thomas Stanka
Guest

Sun Feb 21, 2010 11:08 am

Quote:

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?

Each serious synthesis tool accepts records. Unfortunately some of the
common used tools tend to replace a record by a vector after synthesis
which makes debugging in netlist simulation a pain. Better tools
synthesis to names like record.entry1 and record.entry2.

bye Thomas

Martin Thompson
Guest

Mon Feb 22, 2010 11:00 am

jozamm <jozamm_at_gmail.com> writes:

Quote:

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.

As others have noted, deciding where to draw the boundaries is a bit
of an art.

In terms of routing signals around, records can help with that: if you
want to push an extra signal down the hierarchy, you just add it to
the appropriate record and recompile. However, make sure you package
things together sensibly - by function is often good. Not just "all
the signals to this entity go in one record" as then you can end up
with all the signals in the design in one big record!

Splitting things down into "things that are easy to test" is a good
boundary in my experience. Here's an example - say you want an image
processing system which does an "edge detecting" function, then does a
"peak detecting" function on the results of that and then a "assign
x,y coordinates to each peak we detected" function.

You could stick all of that into one big block of code, but when you
get the wrong x coordinates out of the far end, you have no idea which
subfunction went wrong.

Instead you design three blocks, one for each of the functions, and
test them individually. You can get each part right *in isolation*.

Then when you wire them all together and test it, and it doesn't work
first time (!), you only have to look at the higher-level integration
to see what's wrong.

It may sound like more work this way (writing testbenches doesn't feel
like productive work, especially when you're starting out). But once
you get proficient (which means practicing, just like playing your
scles on the piano Smile

, you can do the testing very quickly because
each individual test is fairly simple. And you can push your design
to all the corner cases, which is much more difficult when testing the
whole thing all together.

Cheers,
Martin

--
martin.j.thompson_at_trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Nial Stewart
Guest

Mon Feb 22, 2010 1:56 pm

Most of what's been posted is good advice.

I usually split design into functional blocks which can then
be indepentantly functionally tested, these are my entities.

When it comes to signal routing I had to pick up a design a while
ago that used records all over the place. I found this obscured the
functional intent and made it much more difficult to debug so I'm not
a big fan, although I have used them in a couple of instances.

Keep it all as simple as possible!

Nial.

Benjamin Couillard
Guest

Mon Feb 22, 2010 10:05 pm

On 22 fév, 07:56, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:

Quote:

Most of what's been posted is good advice.

I usually split design into functional blocks which can then
be indepentantly functionally tested, these are my entities.

When it comes to signal routing I had to pick up a design a while
ago that used records all over the place. I found this obscured the
functional intent and made it much more difficult to debug so I'm not
a big fan, although I have used them in a couple of instances.

Keep it all as simple as possible!

Nial.

I think that records that group "related logic" make design clearer.
The important thing is not to group random signals in a record.
For example, I use records to interface my sdram controller with my
other processing blocks. One record is called "sdram_if_input_t" for
the sdram controller interface inputs and the other one
"sdram_if_output_t" for the controller outputs.
Therefore my block called "video_processing" is connected by 2 signals
to the sdram controller instead of being connected by 10-15 signals to
the sdram controller.

That way the top level is much much clearer since the number of
signals is reduced. The possibility of errors is reduced too because
there's less risk of connecting the wrong signal in the wrong place
with records.

For entities, I think that if you have trouble saying what is the
purpose of the block you're designing, then your block is probably
doing too much or not enough. That's what I aim for. That way it's
easier to reuse the block and the testbench design is also easier. I
also try to use only one process for my entities when possible (After
looking at Mike Treseler's code).

Benjamin

Andy
Guest

Mon Feb 22, 2010 10:48 pm

On Feb 20, 10:24 am, Petter Gustad <newsmailco...@gustad.com> wrote:

Quote:

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.

A record port can only have a single mode, but it can be inout. multi-
directioned records require resolved types and default drivers defined
everywhere those elements are used only as inputs. It requires a lot
of work down below, but at the top level, plumbing is sweet easy to
maintain. Need another signal? Just add it to the record type and to
the default undriven value constant, then you only need to patch it in
where it is ultimately used.

User defined collections of per-element modes for records has been on
my Christmas list for a long time...

Andy