Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 158175

Article: 158175
Subject: Re: Why is this group so quiet?
From: rickman <gnuarm@gmail.com>
Date: Wed, 9 Sep 2015 23:17:25 -0400
Links: << >>  << T >>  << A >>
On 9/9/2015 1:24 PM, lasselangwadtchristensen@gmail.com wrote:
> Den onsdag den 9. september 2015 kl. 08.58.47 UTC+2 skrev rickman:
>> On 9/8/2015 5:20 PM, lasselangwadtchristensen@gmail.com wrote:
>>> Den mandag den 7. september 2015 kl. 20.11.10 UTC+2 skrev rickman:
>>>> On 9/6/2015 5:24 PM, Mike Field wrote:
>>>>> I was just wondering... why is this group so quiet?
>>>>>
>>>>> With lots of interesting news like:
>>>>>
>>>>> Microsoft Extends FPGA Reach From Bing To Deep Learning - http://www.theplatform.net/2015/08/27/microsoft-extends-fpga-reach-from-bing-to-deep-learning/
>>>>>
>>>>> China's FPGA Company - http://www.electronicsweekly.com/mannerisms/fpga/chinas-fpga-company-2015-09/
>>>>>
>>>>> AMD patent filing hints at FPGA plans in the pipeline - http://www.theregister.co.uk/2015/08/11/amd_patent_filing_hints_at_fpga_plans_in_the_pipeline/
>>>>
>>>> AMD getting into the FPGA market would indeed be news.  I seriously
>>>> doubt that will be happening.  There are a lot of financial and patent
>>>> barriers.
>>>>
>>>> I can't currently read any of your links, but it could be interesting if
>>>> China did get into the FPGA market.  But do you think they will market
>>>> much in the US?  I expect they will be pushed as alternatives to the big
>>>> name FPGAs for use in many Chinese products which are more and more
>>>> designed in China.  There aren't many Chinese chips with much complexity
>>>> that are used in other parts of the world.  It can be very hard to get
>>>> much info that is clear.
>>>>
>>>
>>> the company is Gowin semiconductor,
>>>
>>> http://hackaday.com/2015/08/24/two-new-fpga-families-designed-in-china/
>>>
>>> maybe they will have learned something from Espressif and their ~1$ wifi chip
>>> As soon as English documentation and tools started to appear everyone and his cousin started doing stuff cool with them
>>
>> Unfortunately I am still fighting computer problems.  I am unable to
>> view a link unless I write it down and copy it to another machine.  :(
>>
>
> ok, afaict: 55nm,  1152 and 8640 LUTs, on-chip random access flash,
> Synopsys' Synplify Pro for synthesis, qfp100 to BGAs

I found their site and only the small part comes in the 100 pin QFP. 
The larger part only comes in the 256 and larger BGAs.  So no magic for 
me.  The smaller part has no distributed RAM which seems weird and no 
multipliers which is not uncommon.

-- 

Rick

Article: 158176
Subject: Re: Why is this group so quiet?
From: Tim Wescott <tim@seemywebsite.com>
Date: Thu, 10 Sep 2015 00:13:10 -0500
Links: << >>  << T >>  << A >>
On Wed, 09 Sep 2015 01:09:27 -0500, kaz wrote:

>>Tim Wescott wrote:
>>> On Tue, 08 Sep 2015 18:09:22 -0500, Les Cargill wrote:
>>>
>>>> Tim Wescott wrote:
>>>>> On Tue, 08 Sep 2015 14:25:39 -0500, kaz wrote:
>>>>>
>>>>>
>>>>>>> (Actually, I think a USENET question-answering robot would be a
> cool
>>>>>>> thing for someone to try.  After lurking for about a year you can
>>>>>>> answer
>>>>>>
>>>>>>> most questions by just regurgitating answers to previous
> questions.)
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Tim Wescott Wescott Design Services http://www.wescottdesign.com
>>>>>>
>>>>>> The problem of DSPRelated G5 (Gang of 5) is not just answering
> posts
>>>>>> but soon they 5 member gang start fighting each other on their
>>>>>> comments and thoughts.
>>>>>>
>>>>>> It is in most cases waste of time and words to find any useful
> post.
>>>>>
>>>>> You may have a point there.  So, if I'm going to pass a Turing test
>>>>> does this mean that I need to get offended easily?
>>>>>
>>>>>
>>>>>
>>>> I think people do this when they think they might not pass a Turing
>>>> test.
>>>
>>> Are you implying I can't pass a Turing test?
>>>
>>>
>>I am not sure I can because lake bloop forble.
>>
>>
>>> I'm offended.  Or maybe I'm simulating.  Hmm.  How to tell?
>>>
>>>
>>--
>>Les Cargill
> 
> This forum is now under attack by the Robots from next door, really.
> 
> kaz ---------------------------------------
> Posted through http://www.FPGARelated.com

Your objections sound almost -- robotic.



-- 
www.wescottdesign.com

Article: 158177
Subject: Re: Why is this group so quiet?
From: Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>>
Date: Thu, 10 Sep 2015 10:13:50 +0100
Links: << >>  << T >>  << A >>
On Wed, 9 Sep 2015 23:17:25 -0400
rickman <gnuarm@gmail.com> wrote:

> I found their site and only the small part comes in the 100
> pin QFP. The larger part only comes in the 256 and larger
> BGAs.  So no magic for me.  The smaller part has no
> distributed RAM which seems weird and no multipliers which is
> not uncommon.

Go on, bite the bullet!  Try the QFN32 or WLCSP25, you can
get your cheap proto PCBs also from China:

  http://dirtypcbs.com/


There are some oddities about the parts; are there really only 3
flops per four LUTs?  Anyone seen a patent?


 Device       |  GW1N-1K  |  GW1N-9K
 -------------+-----------+---------
 Lut          |   1,152   |  8,640
 FF           |     864   |  6,480
 CLU Array    |   11x20   |  
 Dist. RAM    |      0    |  17,280
 Block SRAM   |    72Kb   |  198Kb
 NVM Bits [1] |    96K    |  1,792K
 Mult. 18x18  |     0     |    20
 Max User IO  |   120     |   272
 PLLs+DLLs    |     0     |   2+3
 WLCSP25      |    15     |  
 QFN32        |    21     |  
 LQFP100      |    79     |  
 LQFP144      |   116     |  
 MBGA160      |   120     |  
 UBGA204      |   120     |  
 PBGA204      |   120     |  
 PBGA256      |           |   180
 PBGA484      |           |   272 

[1] Random Access

Abbreviated from:
http://gowinsemi.com.cn/productsShow.aspx?n_id=353


Jan Coombs
-- 
email valid, else fix dots and hyphen
jan4clf2014@murrayhyphenmicroftdotcodotuk


Article: 158178
Subject: Re: Why is this group so quiet?
From: Svenn Are Bjerkem <svenn.bjerkem@googlemail.com>
Date: Thu, 10 Sep 2015 08:55:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
> I was just wondering... why is this group so quiet?
>=20

Maybe the number of retulars has fallen below the critical mass. Groups sel=
dom show up on google search results when I do search with google. Xilinx h=
as a fairly good support comunity. Few use Microsemi anyway. Few new progra=
mming languages for FPGA released every year.=20

--=20
Svenn

Article: 158179
Subject: Re: How to understand obfuscated IP codes?
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Fri, 11 Sep 2015 05:12:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
Am Mittwoch, 9. September 2015 14:11:48 UTC+2 schrieb Sumathigokul:
> If suppose i received a HDL code for FPGA related design and it is
> obfuscated, how to understand it??? Is there any systematic procedure to
> perform it??

I assume you paid money to get this code. I would request documentation and read it. 

For obfuscated code it is really hard to tell
a <= b + c is iteself hard to read when you have no context, but this is considered not obfuscated. Real obfuscting could be:

a010000:=a001001+1+1
a010100<=a010000+a00100-2


Article: 158180
Subject: Re: Why is this group so quiet?
From: Julian Gardner <joolzg@btinternet.com>
Date: 11 Sep 2015 14:18:17 GMT
Links: << >>  << T >>  << A >>
In reply to "Svenn Are Bjerkem" who wrote the following:

> > I was just wondering... why is this group so quiet?
> > =20
> 
> Maybe the number of retulars has fallen below the critical mass. Groups sel=
> dom show up on google search results when I do search with google. Xilinx h=
> as a fairly good support comunity. Few use Microsemi anyway. Few new progra=
> mming languages for FPGA released every year.=20
> 
> --=20
> Svenn

I think groups like this are quiet because most people join the specific forums 
for a particular chip manufacturer.

If the chip manufacturer's support came on here it would be a lot busier.

joolz



-- 
--------------------------------- --- -- -
Posted with NewsLeecher v7.0 Beta 7
Web @ http://www.newsleecher.com/?usenet
------------------- ----- ---- -- -


Article: 158181
Subject: Re: Why is this group so quiet?
From: rickman <gnuarm@gmail.com>
Date: Fri, 11 Sep 2015 13:09:13 -0400
Links: << >>  << T >>  << A >>
On 9/10/2015 5:13 AM, Jan-54 wrote:
> On Wed, 9 Sep 2015 23:17:25 -0400
> rickman <gnuarm@gmail.com> wrote:
>
>> I found their site and only the small part comes in the 100
>> pin QFP. The larger part only comes in the 256 and larger
>> BGAs.  So no magic for me.  The smaller part has no
>> distributed RAM which seems weird and no multipliers which is
>> not uncommon.
>
> Go on, bite the bullet!  Try the QFN32 or WLCSP25, you can
> get your cheap proto PCBs also from China:
>
>    http://dirtypcbs.com/

I have a product which uses around 80% of 3 KLUT in a 100 QFP.  The 
Lattice part in use is obsolete and I would like to have a replacement. 
  So a 32 QFN is of no use in this app.


> There are some oddities about the parts; are there really only 3
> flops per four LUTs?  Anyone seen a patent?

That is not unusual as you will find in some of the Lattice parts.  Also 
note that more recent parts have grown the LUTs to 6 inputs which 
amounts to having 4 of the 4 input LUTs per FF.


>   Device       |  GW1N-1K  |  GW1N-9K
>   -------------+-----------+---------
>   Lut          |   1,152   |  8,640
>   FF           |     864   |  6,480
>   CLU Array    |   11x20   |
>   Dist. RAM    |      0    |  17,280
>   Block SRAM   |    72Kb   |  198Kb
>   NVM Bits [1] |    96K    |  1,792K
>   Mult. 18x18  |     0     |    20
>   Max User IO  |   120     |   272
>   PLLs+DLLs    |     0     |   2+3
>   WLCSP25      |    15     |
>   QFN32        |    21     |
>   LQFP100      |    79     |
>   LQFP144      |   116     |
>   MBGA160      |   120     |
>   UBGA204      |   120     |
>   PBGA204      |   120     |
>   PBGA256      |           |   180
>   PBGA484      |           |   272
>
> [1] Random Access
>
> Abbreviated from:
> http://gowinsemi.com.cn/productsShow.aspx?n_id=353

They seem to be following in the footsteps of the large FPGA makers, in 
particular Lattice.  Any idea of what the various dimensions of the 
MBGA160 are?  My problem with BGA is when the ball pitch gets too small 
that I have to drop from 6/6 design rules (maybe 5/5 these days).

-- 

Rick

Article: 158182
Subject: Re: Why is this group so quiet?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 11 Sep 2015 18:17:14 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
> On 9/10/2015 5:13 AM, Jan-54 wrote:

(snip)
>> There are some oddities about the parts; are there really only 3
>> flops per four LUTs?  Anyone seen a patent?
 
> That is not unusual as you will find in some of the Lattice parts.  Also 
> note that more recent parts have grown the LUTs to 6 inputs which 
> amounts to having 4 of the 4 input LUTs per FF.

Someone should know the scaling laws for logic, which should show
how the number of FF scales with LUTs, and how 4LUTs scale relative
to 6LUTs. 

Note that a 6LUT isn't quite as useful as four 4LUTs.
(Especially if you need a FF at an appropriate point.)

Seems to me that FPGA designers are getting closer to what is actually
used in the usual case, and optimizing more for that.

-- glen

Article: 158183
Subject: low-level vs. high-level
From: Evgeny Filatov <e.v.filatov@ieee.org>
Date: Sat, 12 Sep 2015 00:18:59 +0300
Links: << >>  << T >>  << A >>
Hi,

I use graphical high-level tools to design DSP stuff and generate RTL 
for it. It works for me, but I started to suspect that it is more 
efficient to write RTL in HDL languages instead.

Is there any general rule of thumb for how much is sacrificed (in terms 
of area / performance) by using high-level tools, as opposed to writing 
RTL manually in VHDL/Verilog?

Regards,
Evgeny.

Article: 158184
Subject: Re: Why is this group so quiet?
From: rickman <gnuarm@gmail.com>
Date: Fri, 11 Sep 2015 18:30:11 -0400
Links: << >>  << T >>  << A >>
On 9/11/2015 2:17 PM, glen herrmannsfeldt wrote:
> rickman <gnuarm@gmail.com> wrote:
>> On 9/10/2015 5:13 AM, Jan-54 wrote:
>
> (snip)
>>> There are some oddities about the parts; are there really only 3
>>> flops per four LUTs?  Anyone seen a patent?
>
>> That is not unusual as you will find in some of the Lattice parts.  Also
>> note that more recent parts have grown the LUTs to 6 inputs which
>> amounts to having 4 of the 4 input LUTs per FF.
>
> Someone should know the scaling laws for logic, which should show
> how the number of FF scales with LUTs, and how 4LUTs scale relative
> to 6LUTs.

There is no such thing as a scaling "law".  Different designs are 
different.  That's why different chips from the same maker have 
different ratios... different target markets.


> Note that a 6LUT isn't quite as useful as four 4LUTs.
> (Especially if you need a FF at an appropriate point.)

Not sure what your point is.  This completely ignores the main issue 
which is designing the most useful FPGA for the cost.  As devices have 
grown in size they found the routing was hogging too much real estate so 
they needed to push up from the bottom to eliminate the lowest level of 
interconnect.  LUT6 based blocks get rid of a lot of low end routing in 
essence.

Remember, they sell you the routing and give you the logic for free.


> Seems to me that FPGA designers are getting closer to what is actually
> used in the usual case, and optimizing more for that.

I think this is a poor way of understanding what is needed in FPGAs.  As 
devices grow, logic blocks grow.  Consider the memory block, the 
multiplier/DSP block and now full fledged CPUs all "part" of the FPGA. 
This trend will continue with more and more built in functions being 
included as hard IP rather than soft IP using the FPGA fabric.

If we could get them to make FPGAs at the low end with better I/O 
capability (analog functions, clock oscillators, etc) such as is found 
in MCUs, they might just take out many of the general MCUs.  How long 
can they continue to grow at the top end?

-- 

Rick

Article: 158185
Subject: Re: low-level vs. high-level
From: BobH <wanderingmetalhead.nospam.please@yahoo.com>
Date: Fri, 11 Sep 2015 16:23:55 -0700
Links: << >>  << T >>  << A >>
On 9/11/2015 2:18 PM, Evgeny Filatov wrote:
> Hi,
>
> I use graphical high-level tools to design DSP stuff and generate RTL
> for it. It works for me, but I started to suspect that it is more
> efficient to write RTL in HDL languages instead.
>
> Is there any general rule of thumb for how much is sacrificed (in terms
> of area / performance) by using high-level tools, as opposed to writing
> RTL manually in VHDL/Verilog?
>
> Regards,
> Evgeny.

If you are using a good optimizing synthesis tool chain, the difference 
may not be very large. I used some Mathcad generated RTL on a project, 
and by the time the synthesis tool was done, it was as tight as I could 
have gotten it by hand.

Regards,
BobH

Article: 158186
Subject: Re: Why is this group so quiet?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 12 Sep 2015 03:34:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

(snip, I wrote)

>> Someone should know the scaling laws for logic, which should show
>> how the number of FF scales with LUTs, and how 4LUTs scale relative
>> to 6LUTs.

> There is no such thing as a scaling "law".  Different designs are 
> different.  That's why different chips from the same maker have 
> different ratios... different target markets.

Different designs are different, but usually there is a trend.

There are, for example, scaling laws for MOS transistors, even 
though there are differences in the way individual ones are made.

If you make a log-log graph with the number of gates on one axis
and number of FF on the other, you can see if there is a trend.
Most often, there is.
 
>> Note that a 6LUT isn't quite as useful as four 4LUTs.
>> (Especially if you need a FF at an appropriate point.)
 
> Not sure what your point is.  This completely ignores the main issue 
> which is designing the most useful FPGA for the cost.  As devices have 
> grown in size they found the routing was hogging too much real estate so 
> they needed to push up from the bottom to eliminate the lowest level of 
> interconnect.  LUT6 based blocks get rid of a lot of low end routing in 
> essence.

Yes.

So, as you note, routing increases faster than logic as logic grows.
There will be an exponent, likely between 1 and 2, that shows how
it grows.
 
> Remember, they sell you the routing and give you the logic for free.
 
>> Seems to me that FPGA designers are getting closer to what is actually
>> used in the usual case, and optimizing more for that.
 
> I think this is a poor way of understanding what is needed in FPGAs.  As 
> devices grow, logic blocks grow.  Consider the memory block, the 
> multiplier/DSP block and now full fledged CPUs all "part" of the FPGA. 
> This trend will continue with more and more built in functions being 
> included as hard IP rather than soft IP using the FPGA fabric.

I suppose, but since different designs are different, it might need
a few different types of chips. Some designs have no use for block
RAM or multipliers, no matter how useful they are on average.
 
> If we could get them to make FPGAs at the low end with better I/O 
> capability (analog functions, clock oscillators, etc) such as is found 
> in MCUs, they might just take out many of the general MCUs.  How long 
> can they continue to grow at the top end?

Could be interesting.

-- glen




Article: 158187
Subject: Re: low-level vs. high-level
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 12 Sep 2015 03:42:00 +0000 (UTC)
Links: << >>  << T >>  << A >>
Evgeny Filatov <e.v.filatov@ieee.org> wrote:
 
> I use graphical high-level tools to design DSP stuff and generate RTL 
> for it. It works for me, but I started to suspect that it is more 
> efficient to write RTL in HDL languages instead.

I am not sure what there is in high-level tools. 

If you mean schematic capture, I find it a lot of work for many
actual problems. 

But it might be that some people are more visual than others,
and find it hard to read and understand HDL. 
 
> Is there any general rule of thumb for how much is sacrificed (in terms 
> of area / performance) by using high-level tools, as opposed to writing 
> RTL manually in VHDL/Verilog?

Most of the designs I work on are pretty low level, but if you write
the appropriate modules (or entities), you should be able to make it
look right in HDL. Write modules for high-level DSP blocks and wire
them up with HDL.

I write structural verilog, or more recently structural VHDL. 

-- glen

Article: 158188
Subject: I am getting errors when i run a systemC Code in edaplayground
From: ecebharath@gmail.com
Date: Fri, 11 Sep 2015 21:48:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I am getting below errors when i use systemc in edaplayground

error: 'sc_sgnal' was not declared in this scope.

I have added systemC2.3 library aswell.

using C++ Copiler.

Please help me 

Thanks
Bharath

Article: 158189
Subject: Re: Why is this group so quiet?
From: rickman <gnuarm@gmail.com>
Date: Sat, 12 Sep 2015 02:08:11 -0400
Links: << >>  << T >>  << A >>
On 9/11/2015 11:34 PM, glen herrmannsfeldt wrote:
> rickman <gnuarm@gmail.com> wrote:
>
> (snip, I wrote)
>
>>> Someone should know the scaling laws for logic, which should show
>>> how the number of FF scales with LUTs, and how 4LUTs scale relative
>>> to 6LUTs.
>
>> There is no such thing as a scaling "law".  Different designs are
>> different.  That's why different chips from the same maker have
>> different ratios... different target markets.
>
> Different designs are different, but usually there is a trend.
>
> There are, for example, scaling laws for MOS transistors, even
> though there are differences in the way individual ones are made.
>
> If you make a log-log graph with the number of gates on one axis
> and number of FF on the other, you can see if there is a trend.
> Most often, there is.

I get what a trend is.  I'm saying that the people from the FPGA 
companies have said there are wide variations based on the type of 
design being done.  They shoot for the best compromise, but even that 
depends on a variety of factors.  As I said before, even within one 
maker's lines, the ratio varies.  So clearly there are different markets 
and not a one-size-fits-all.


>>> Note that a 6LUT isn't quite as useful as four 4LUTs.
>>> (Especially if you need a FF at an appropriate point.)
>
>> Not sure what your point is.  This completely ignores the main issue
>> which is designing the most useful FPGA for the cost.  As devices have
>> grown in size they found the routing was hogging too much real estate so
>> they needed to push up from the bottom to eliminate the lowest level of
>> interconnect.  LUT6 based blocks get rid of a lot of low end routing in
>> essence.
>
> Yes.
>
> So, as you note, routing increases faster than logic as logic grows.
> There will be an exponent, likely between 1 and 2, that shows how
> it grows.
>
>> Remember, they sell you the routing and give you the logic for free.
>
>>> Seems to me that FPGA designers are getting closer to what is actually
>>> used in the usual case, and optimizing more for that.
>
>> I think this is a poor way of understanding what is needed in FPGAs.  As
>> devices grow, logic blocks grow.  Consider the memory block, the
>> multiplier/DSP block and now full fledged CPUs all "part" of the FPGA.
>> This trend will continue with more and more built in functions being
>> included as hard IP rather than soft IP using the FPGA fabric.
>
> I suppose, but since different designs are different, it might need
> a few different types of chips. Some designs have no use for block
> RAM or multipliers, no matter how useful they are on average.

And that is the sticky wicket!  FPGA makers have resisted adding lots of 
hard IP (especially CPUs) because of the proliferation of combinations 
that ensue.  With block memory and multipliers they generally picked a 
ratio to logic and worked with that.  But even there, they have come out 
with lines with more or less of these relatively generic blocks 
depending on the applications.  CPUs are a horse of another color.   If 
you can work with off chip memory, that at least is out of the equation. 
  Eventually there will be more and more hard IP used and FPGAs will 
proliferate the same way MCUs have.  Or will it be that FPGA fabric will 
be added to CPUs and FPGAs will go the way of the PDA?


>> If we could get them to make FPGAs at the low end with better I/O
>> capability (analog functions, clock oscillators, etc) such as is found
>> in MCUs, they might just take out many of the general MCUs.  How long
>> can they continue to grow at the top end?
>
> Could be interesting.

Needs to be economically "interesting" to the FPGA companies.  Atmel had 
one at one time, but their technology was behind the power curve and 
they could never bring the cost down.  Now Microsemi has a line of them 
with the same cost problem.

-- 

Rick

Article: 158190
Subject: Re: low-level vs. high-level
From: rickman <gnuarm@gmail.com>
Date: Sat, 12 Sep 2015 02:09:49 -0400
Links: << >>  << T >>  << A >>
On 9/11/2015 11:42 PM, glen herrmannsfeldt wrote:
> Evgeny Filatov <e.v.filatov@ieee.org> wrote:
>
>> I use graphical high-level tools to design DSP stuff and generate RTL
>> for it. It works for me, but I started to suspect that it is more
>> efficient to write RTL in HDL languages instead.
>
> I am not sure what there is in high-level tools.
>
> If you mean schematic capture, I find it a lot of work for many
> actual problems.
>
> But it might be that some people are more visual than others,
> and find it hard to read and understand HDL.
>
>> Is there any general rule of thumb for how much is sacrificed (in terms
>> of area / performance) by using high-level tools, as opposed to writing
>> RTL manually in VHDL/Verilog?
>
> Most of the designs I work on are pretty low level, but if you write
> the appropriate modules (or entities), you should be able to make it
> look right in HDL. Write modules for high-level DSP blocks and wire
> them up with HDL.
>
> I write structural verilog, or more recently structural VHDL.

I'm not sure what you mean by that.  Everyone writes structural HDL. 
But they also write the code in the blocks that gets connected by the 
structural HDL.  Don't you?  That is the hard part.

-- 

Rick

Article: 158191
Subject: Re: I am getting errors when i run a systemC Code in edaplayground
From: HT-Lab <hans64@htminuslab.com>
Date: Sat, 12 Sep 2015 09:10:01 +0100
Links: << >>  << T >>  << A >>
On 12/09/2015 05:48, ecebharath@gmail.com wrote:
> Hi,
>
> I am getting below errors when i use systemc in edaplayground
>
I would suggest you compile your own local library as it will give you a 
more convenient and quicker working environment. Just google how to do it.

> error: 'sc_sgnal' was not declared in this scope.
>
sc_signal?

Hans
www.ht-lab.com

> I have added systemC2.3 library aswell.
>
> using C++ Copiler.
>
> Please help me
>
> Thanks
> Bharath
>


Article: 158192
Subject: Re: low-level vs. high-level
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 12 Sep 2015 13:33:50 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

(snip)

>> I write structural verilog, or more recently structural VHDL.
 
> I'm not sure what you mean by that.  Everyone writes structural HDL. 
> But they also write the code in the blocks that gets connected by the 
> structural HDL.  Don't you?  That is the hard part.

I write a very small part of my verilog in always blocks, 
or vhdl in process blocks, and usually in leaf modules/entities.

As well as I know, not everyone does that. 

The verilog books that I know make a bigger distinction between
behavioral and structural than the VHDL books, but both have it.

Many always/process blocks have one statement in them, though
sometimes two or three. A loadable counter with reset might go
in one.

-- glen


Article: 158193
Subject: Re: low-level vs. high-level
From: rickman <gnuarm@gmail.com>
Date: Sat, 12 Sep 2015 11:15:18 -0400
Links: << >>  << T >>  << A >>
On 9/12/2015 9:33 AM, glen herrmannsfeldt wrote:
> rickman <gnuarm@gmail.com> wrote:
>
> (snip)
>
>>> I write structural verilog, or more recently structural VHDL.
>
>> I'm not sure what you mean by that.  Everyone writes structural HDL.
>> But they also write the code in the blocks that gets connected by the
>> structural HDL.  Don't you?  That is the hard part.
>
> I write a very small part of my verilog in always blocks,
> or vhdl in process blocks, and usually in leaf modules/entities.
>
> As well as I know, not everyone does that.

How else do people write their code?


> The verilog books that I know make a bigger distinction between
> behavioral and structural than the VHDL books, but both have it.
>
> Many always/process blocks have one statement in them, though
> sometimes two or three. A loadable counter with reset might go
> in one.

Sure, the two are very different.  Behavioral code requires thinking and 
analysis.  Structural code is just a matter of wiring together blocks.

I think maybe what you are saying is that you only write behavioral code 
for very small logical functions and create more complex functions by 
wiring them together.  This would be analogous to designing a board 
using SSI and MSI logic while others write behavioral modules more like 
LSI and and VLSI, only using the structural code for the greatly reduced 
interconnect.

The main reason I can see for writing code using less structural and 
more behavioral code is the greatly reduced code required.  But then I'm 
not sure it would be greatly reduced.  I'm just familiar with 
interconnecting larger blocks where structural code is a PITA because of 
the verbosity.  Each signal has to be declared in the higher module, 
listed in the instantiation and declared as I/O in the lower module. 
This can be so tedious that I have rather lengthy regular expressions I 
keep in my code to automagically convert between them.

Actually, I realize using structural code at the lower levels would be 
*very* verbose because none of the higher level structural code is 
reduced.  So writing high and mid-level modules in structural code would 
add lots of verbiage.

Once a process is defined, it can add another register with just three 
rather simple lines of code.  Declare the signal, initialize the signal 
and assign the signal.  Even creating a new process only adds two more 
lines.  Structural code for this requires at least as many lines of code 
along with any generics and the common signals like reset and clocks. 
Well, I count a lot of lines because I write in a spread out manner with 
each I/O signal on it's own line.  If you come from the Verilog world 
your style may vary.

Still, I think the high and mid-level modules will become rather verbose 
with structural code.

-- 

Rick

Article: 158194
Subject: Re: low-level vs. high-level
From: Tim Wescott <tim@seemywebsite.com>
Date: Sat, 12 Sep 2015 11:09:07 -0500
Links: << >>  << T >>  << A >>
On Sat, 12 Sep 2015 03:42:00 +0000, glen herrmannsfeldt wrote:

> Evgeny Filatov <e.v.filatov@ieee.org> wrote:
>  
>> I use graphical high-level tools to design DSP stuff and generate RTL
>> for it. It works for me, but I started to suspect that it is more
>> efficient to write RTL in HDL languages instead.
> 
I'm assuming he means that he draws up a block diagram in Simulink and 
then pushes a button (well, maybe after lots of simulation and analysis).

But I'm just assuming.

-- 
www.wescottdesign.com

Article: 158195
Subject: Re: I am getting errors when i run a systemC Code in edaplayground
From: ecebharath@gmail.com
Date: Sat, 12 Sep 2015 09:16:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi,

I am using eda playground.In which they provided the libraries to be included.

Even after i have included the libraries also i am getting the error that is not finding the sc_signals class.

Thanks
Bharath


On Saturday, 12 September 2015 16:10:11 UTC+8, HT-Lab  wrote:
> On 12/09/2015 05:48, ecebharath@gmail.com wrote:
> > Hi,
> >
> > I am getting below errors when i use systemc in edaplayground
> >
> I would suggest you compile your own local library as it will give you a 
> more convenient and quicker working environment. Just google how to do it.
> 
> > error: 'sc_sgnal' was not declared in this scope.
> >
> sc_signal?
> 
> Hans
> www.ht-lab.com
> 
> > I have added systemC2.3 library aswell.
> >
> > using C++ Copiler.
> >
> > Please help me
> >
> > Thanks
> > Bharath
> >


Article: 158196
Subject: Re: low-level vs. high-level
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 12 Sep 2015 18:00:24 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:

(snip, I wrote0h)
>>>> I write structural verilog, or more recently structural VHDL.

>>> I'm not sure what you mean by that.  Everyone writes structural HDL.
>>> But they also write the code in the blocks that gets connected by the
>>> structural HDL.  Don't you?  That is the hard part.

>> I write a very small part of my verilog in always blocks,
>> or vhdl in process blocks, and usually in leaf modules/entities.

>> As well as I know, not everyone does that.
 
> How else do people write their code?

Well, in verilog you can write combinatorial logic with either
continuous assignment not in an always block, or a behavioral
assignment (that is what the book nearby seems to call it) in
an always block. Two different ways to say the same thing.

The only way I make registers and latches in verilog is with
an always block. It might be that it can be done in VHDL without
a process block, but so far I use one, such that it looks similar
to the matching verilog. 
 
>> The verilog books that I know make a bigger distinction between
>> behavioral and structural than the VHDL books, but both have it.

>> Many always/process blocks have one statement in them, though
>> sometimes two or three. A loadable counter with reset might go
>> in one.
 
> Sure, the two are very different.  Behavioral code requires thinking and 
> analysis.  Structural code is just a matter of wiring together blocks.

I consider continuous assignment part of structural, though it might
have another name, and some logic goes in there. 
 
> I think maybe what you are saying is that you only write behavioral code 
> for very small logical functions and create more complex functions by 
> wiring them together.  This would be analogous to designing a board 
> using SSI and MSI logic while others write behavioral modules more like 
> LSI and and VLSI, only using the structural code for the greatly reduced 
> interconnect.

Some can be written about the same either way.  When I have a 
choice between verilog continuous assignment and behavioral assignment,
I choose the former, others might choose the latter.

I usually put registers into their own module, even if that is the
only thing in the module. 

One that I am working on now is exactly taking a design in SSI and
MSI and writing it in VHDL. The SSI (gates) go into assignment
statements with the appropriate logical operations. MSI (anything
more complicated than just gates) into a module. I can verify the
operation of the module once, and use it many times.

> The main reason I can see for writing code using less structural and 
> more behavioral code is the greatly reduced code required.  But then I'm 
> not sure it would be greatly reduced.  I'm just familiar with 
> interconnecting larger blocks where structural code is a PITA because of 
> the verbosity.  Each signal has to be declared in the higher module, 
> listed in the instantiation and declared as I/O in the lower module. 
> This can be so tedious that I have rather lengthy regular expressions I 
> keep in my code to automagically convert between them.

As far as I know, some people like the way it looks more like a
software (sequential) programming language. 
 
> Actually, I realize using structural code at the lower levels would be 
> *very* verbose because none of the higher level structural code is 
> reduced.  So writing high and mid-level modules in structural code would 
> add lots of verbiage.

Well, for example, I might write a multiplexer in a module, nice
combinatorial logic with no registers, then use that module wherever
I need a multiplexer, instead of rewriting one each time.

Internally, that module will use either the verilog conditional
operator or VHDL WHEN operator. (Being use to C, I find the WHEN
syntax a little strange, but it doesn't take long to get used to.)

I suspect others will build a multiplexer using behavioral if
statements in either language. 

OK, here is a multiplexer in VHDL:

library IEEE;
use IEEE.std_logic_1164.all;

entity N157 is
  port (
    Y : out std_logic_vector(3 downto 0);
    A, B : in std_logic_vector(3 downto 0);
    S, G: std_logic);
end entity N157;

architecture N157 of N157 is
begin
   Y <= X"0" when G='1' else A when S='0' else B;
end architecture N157;
 
> Once a process is defined, it can add another register with just three 
> rather simple lines of code.  Declare the signal, initialize the signal 
> and assign the signal.  Even creating a new process only adds two more 
> lines.  Structural code for this requires at least as many lines of code 
> along with any generics and the common signals like reset and clocks. 
> Well, I count a lot of lines because I write in a spread out manner with 
> each I/O signal on it's own line.  If you come from the Verilog world 
> your style may vary.

If it fits reasonably, I put a whole module/entity instatiation
on one line. I stay within 80 characters (for one, so that they print
nicely), so some will take more lines. Maybe that is from using
verilog first.
 
> Still, I think the high and mid-level modules will become rather verbose 
> with structural code.

My early verilog was systolic arrays, with repeated blocks of fairly
simple code. The mid-level module fit on one or two pages, matching
fairly closely the register transfer logic that one might write.
Lower level were registers, adders, comparators, and multiplexers.
Top level instantiated some number of the unit cell in a linear array.

-- glen
 

Article: 158197
Subject: Re: low-level vs. high-level
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sat, 12 Sep 2015 18:10:26 +0000 (UTC)
Links: << >>  << T >>  << A >>
Tim Wescott <tim@seemywebsite.com> wrote:
(snip)
>> Evgeny Filatov <e.v.filatov@ieee.org> wrote:
  
>>> I use graphical high-level tools to design DSP stuff and generate RTL
>>> for it. It works for me, but I started to suspect that it is more
>>> efficient to write RTL in HDL languages instead.
 
> I'm assuming he means that he draws up a block diagram in Simulink and 
> then pushes a button (well, maybe after lots of simulation and analysis).
 
> But I'm just assuming.

I do remember using schematic drawing tools, but most often found
it took a lot of work drawing lines, making sure that they didn't
overlap what they weren't supposed to, and otherwise getting it right.

But I can write some lines of verilog or VHDL and not have to worry
about such lines overlapping. Match up signal names and everything
works the way it is supposed to.

But I suppose something like simulink isn't so bad. Generate the
VHDL or verilog, look at it, and see if it looks right.

-- glen



Article: 158198
Subject: Re: low-level vs. high-level
From: rickman <gnuarm@gmail.com>
Date: Sat, 12 Sep 2015 16:06:46 -0400
Links: << >>  << T >>  << A >>
On 9/12/2015 2:00 PM, glen herrmannsfeldt wrote:
> rickman <gnuarm@gmail.com> wrote:
>
> (snip, I wrote0h)
>>>>> I write structural verilog, or more recently structural VHDL.
>
>>>> I'm not sure what you mean by that.  Everyone writes structural HDL.
>>>> But they also write the code in the blocks that gets connected by the
>>>> structural HDL.  Don't you?  That is the hard part.
>
>>> I write a very small part of my verilog in always blocks,
>>> or vhdl in process blocks, and usually in leaf modules/entities.
>
>>> As well as I know, not everyone does that.
>
>> How else do people write their code?
>
> Well, in verilog you can write combinatorial logic with either
> continuous assignment not in an always block, or a behavioral
> assignment (that is what the book nearby seems to call it) in
> an always block. Two different ways to say the same thing.
>
> The only way I make registers and latches in verilog is with
> an always block. It might be that it can be done in VHDL without
> a process block, but so far I use one, such that it looks similar
> to the matching verilog.

Yes, if you want, you can describe a FF in a continuous assignment in 
VHDL, but it is very unconventional and not very malleable.

I'm not sure why you are drawing some of the distinctions you do.  I 
have never seen anyone consider continuous assignments to be 
"structural" HDL.  Rather complex logic can be defined that way although 
I think most logic ends up in processes or the equivalent.


>>> The verilog books that I know make a bigger distinction between
>>> behavioral and structural than the VHDL books, but both have it.
>
>>> Many always/process blocks have one statement in them, though
>>> sometimes two or three. A loadable counter with reset might go
>>> in one.
>
>> Sure, the two are very different.  Behavioral code requires thinking and
>> analysis.  Structural code is just a matter of wiring together blocks.
>
> I consider continuous assignment part of structural, though it might
> have another name, and some logic goes in there.

I only consider instantiations to be structural.  Continuous assignments 
have several logical constructs which will infer logic and are often 
used that way.  It is actually seldom that I use continuous assignments 
for structure since the connections are made in the component 
instantiations.  Why would I want to connect two wires with an 
assignment unless there was something very odd going on like one wire 
into a module connected to two wires going out?  I don't know I have 
ever done that.


>> I think maybe what you are saying is that you only write behavioral code
>> for very small logical functions and create more complex functions by
>> wiring them together.  This would be analogous to designing a board
>> using SSI and MSI logic while others write behavioral modules more like
>> LSI and and VLSI, only using the structural code for the greatly reduced
>> interconnect.
>
> Some can be written about the same either way.  When I have a
> choice between verilog continuous assignment and behavioral assignment,
> I choose the former, others might choose the latter.

Not sure why that matters.  If it generates logic, it is not structural. 
  I think we have a *big* difference in definitions.  Behavioral does 
not imply any type of assignment to me.  It is a method of designing 
logic by describing how the logic works rather than describing how it is 
constructed.  Both concurrent and sequential coding is used for 
behavioral design.

Purely structural design would use instantiation only without inference 
by any statement type other than within the primitive units.

Of course my designs are never purely behavioral without use of module 
instantiation.  It is easier to test a design in pieces, then glue the 
pieces together and test again.  I think our disagreement is how far 
down the modules are divided.  My typical module size is a couple dozen 
to a hundred or so lines.  Although the really large ones are the top 
level gluing it all together with structural code.  One of my smaller 
top level modules is over 600 lines of glue.  Not hard to get right 
using the tools that let me copy and paste with regular expression 
conversions.  Errors creep in when changes are made.


> I usually put registers into their own module, even if that is the
> only thing in the module.
>
> One that I am working on now is exactly taking a design in SSI and
> MSI and writing it in VHDL. The SSI (gates) go into assignment
> statements with the appropriate logical operations. MSI (anything
> more complicated than just gates) into a module. I can verify the
> operation of the module once, and use it many times.

MSI is a very basic functional block.  If you are using this very often 
you likely are working at a very low level.

The point is that it is not rocket science to code a shift register or 
counter.  There is very little value in being able to say you have a 
verified counter module.  Not much different than saying you have a 
verified multiplexor module which you say you do in continuous assignments.

In the end, using such MSI components can be as error prone as writing 
them from scratch.  I avoid most errors in behavioral code by pulling up 
an existing file and copying an arbitrary process for a registered 
function and then editing the code.  It also reduces the tedium.  Then I 
can focus on the specifics of what this function needs to do other than 
be a register.


>> The main reason I can see for writing code using less structural and
>> more behavioral code is the greatly reduced code required.  But then I'm
>> not sure it would be greatly reduced.  I'm just familiar with
>> interconnecting larger blocks where structural code is a PITA because of
>> the verbosity.  Each signal has to be declared in the higher module,
>> listed in the instantiation and declared as I/O in the lower module.
>> This can be so tedious that I have rather lengthy regular expressions I
>> keep in my code to automagically convert between them.
>
> As far as I know, some people like the way it looks more like a
> software (sequential) programming language.

Not sure what you mean by this.  Only the guts of processes, procedures 
and functions look and feel like a sequential language.  I think we may 
be talking about different things because you include continuous 
assignments as "structural".


>> Actually, I realize using structural code at the lower levels would be
>> *very* verbose because none of the higher level structural code is
>> reduced.  So writing high and mid-level modules in structural code would
>> add lots of verbiage.
>
> Well, for example, I might write a multiplexer in a module, nice
> combinatorial logic with no registers, then use that module wherever
> I need a multiplexer, instead of rewriting one each time.

Yeah, that is the level of design that should be like falling off a log. 
  It is a one liner in a continuous assignment, five lines in a process 
with two of them being ELSE and END IF;

Here is an example...

   SineAmpWord <= LUT_Data when ('0' = PhaseSign) else - LUT_Data;

--- or ---
	if ('0' = PhaseSign) then
	  SineAmpWord	<= LUT_Data;
	else
	  SineAmpWord	<= - LUT_Data;
	end if;

A great reason for inferring this logic is because the tools may decide 
to skip the mux and use an adder with one input being a N bit bus of the 
control signal saving a bunch of logic.  If I hardwired it as a mux it 
would not be as efficient and coding it this way I don't have to think 
about it.  Then again the tools would likely optimize it either way. lol


> Internally, that module will use either the verilog conditional
> operator or VHDL WHEN operator. (Being use to C, I find the WHEN
> syntax a little strange, but it doesn't take long to get used to.)
>
> I suspect others will build a multiplexer using behavioral if
> statements in either language.
>
> OK, here is a multiplexer in VHDL:
>
> library IEEE;
> use IEEE.std_logic_1164.all;
>
> entity N157 is
>    port (
>      Y : out std_logic_vector(3 downto 0);
>      A, B : in std_logic_vector(3 downto 0);
>      S, G: std_logic);
> end entity N157;
>
> architecture N157 of N157 is
> begin
>     Y <= X"0" when G='1' else A when S='0' else B;
> end architecture N157;

This is a terrible multiplexor module in VHDL.  It is exactly 4 bits 
wide when it could have been made N bits wide.  Also it only works for 
SLV data type when the example I use above will work for any types 
available.  BTW, what's with the name N157?  Wouldn't it be better to 
use something more descriptive?  Otherwise, notice that all the work is 
done in one line.  Why go to all the trouble of the above when you only 
need the one line?

Here is an example of a 5 to 1 mux by instantiation from a VHDL lecture.

--5:1 mux, 1 bit wide
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
LIBRARY adk;
USE adk.all;
ENTITY mux5_1_1wide IS
   PORT(
      a_input   : IN STD_LOGIC;  --input a
      b_input   : IN STD_LOGIC;  --input b
      c_input   : IN STD_LOGIC;  --input c
      d_input   : IN STD_LOGIC;  --input d
      e_input   : IN STD_LOGIC;  --input e
      sel       : IN STD_LOGIC_VECTOR(2 DOWNTO 0);  --sel input
      z_out     : OUT STD_LOGIC  --data out
      );
END mux5_1_1wide;
ARCHITECTURE beh OF mux5_1_1wide IS
   SIGNAL temp0, temp1, temp2, temp3 : STD_LOGIC;
   COMPONENT mux21 PORT( a0,a1,s0 : IN  STD_LOGIC;
                                y : OUT STD_LOGIC);  END COMPONENT;
   COMPONENT inv01 PORT(  a : IN  STD_LOGIC;
                          y : OUT STD_LOGIC);  END COMPONENT;
   BEGIN
   U1 : mux21 PORT MAP(a0  => a_input,
                       a1  => b_input,
                       s0  => sel(0),
                        y  => temp0);
   U2 : mux21 PORT MAP(a0  => c_input,
                       a1  => d_input,
                       s0  => sel(0),
                        y  => temp1);
   U3 : mux21 PORT MAP(a0  => temp0,
                       a1  => temp1,
                       s0  => sel(1),
                        y  => temp2);
   U4 : mux21 PORT MAP(a0  => temp2,
                       a1  => e_input,
                       s0  => sel(2),
                        y  => temp3);
   U5 : inv01  PORT MAP(a   => temp3,
                        y   => z_out);
  END beh;

Using behavioral descriptions.

--5:1 mux, 1 bit wide
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
LIBRARY adk;
USE adk.all;
ENTITY mux5_1_1wide IS
PORT(
a_input : IN STD_LOGIC; --input a
b_input : IN STD_LOGIC; --input b
c_input : IN STD_LOGIC; --input c
d_input : IN STD_LOGIC; --input d
e_input : IN STD_LOGIC; --input e
sel : IN STD_LOGIC_VECTOR(2 DOWNTO 0); --sel input
z_out : OUT STD_LOGIC --data out
);
END mux5_1_1wide;
ARCHITECTURE beh OF mux5_1_1wide IS
  BEGIN
    with sel select z_out <=
       a_input when 0, -- count/2 = 1 for this choice
       b_input when 1,
       c_input when 2,
       d_input when 3,
       e_input when others;
  END beh;

Which is simpler and more clear?  If you were coding something more 
complex, would you really want to code it by assembling pieces rather 
than just describing what it does?  I had to use the schematic produced 
by synthesis to see what was done in the case of sel > 4 so I could code 
the behavioral logic the same.


>> Once a process is defined, it can add another register with just three
>> rather simple lines of code.  Declare the signal, initialize the signal
>> and assign the signal.  Even creating a new process only adds two more
>> lines.  Structural code for this requires at least as many lines of code
>> along with any generics and the common signals like reset and clocks.
>> Well, I count a lot of lines because I write in a spread out manner with
>> each I/O signal on it's own line.  If you come from the Verilog world
>> your style may vary.
>
> If it fits reasonably, I put a whole module/entity instatiation
> on one line. I stay within 80 characters (for one, so that they print
> nicely), so some will take more lines. Maybe that is from using
> verilog first.

To do that you need to use positional association which is error prone. 
  Not a big deal for small entities, but harder to get right for large 
ones with lots of I/O.  I *always* use named association to prevent 
difficult to find errors.


>> Still, I think the high and mid-level modules will become rather verbose
>> with structural code.
>
> My early verilog was systolic arrays, with repeated blocks of fairly
> simple code. The mid-level module fit on one or two pages, matching
> fairly closely the register transfer logic that one might write.
> Lower level were registers, adders, comparators, and multiplexers.
> Top level instantiated some number of the unit cell in a linear array.

There will be some designs that suit instantiation well.  I remember a 
frequent poster here with a company specializing in high speed design in 
Xilinx devices.  He used hierarchical schematic design since it gave him 
complete control over both the logic and placement via attributes 
attached to the various symbols.  When the rest of the world was moving 
to HDL, he resisted until he was shown how he could do exactly the same 
things in VHDL.  He never looked back.  Clearly structural HDL was the 
way to go for him.

-- 

Rick

Article: 158199
Subject: Re: low-level vs. high-level
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 13 Sep 2015 05:35:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
(snip, I wrote)
>>>>>> I write structural verilog, or more recently structural VHDL.

>>>>> I'm not sure what you mean by that.  Everyone writes structural HDL.
>>>>> But they also write the code in the blocks that gets connected by the
>>>>> structural HDL.  Don't you?  That is the hard part.

(snip, I wrote)

>> Well, in verilog you can write combinatorial logic with either
>> continuous assignment not in an always block, or a behavioral
>> assignment (that is what the book nearby seems to call it) in
>> an always block. Two different ways to say the same thing.

>> The only way I make registers and latches in verilog is with
>> an always block. It might be that it can be done in VHDL without
>> a process block, but so far I use one, such that it looks similar
>> to the matching verilog.
 
> Yes, if you want, you can describe a FF in a continuous assignment in 
> VHDL, but it is very unconventional and not very malleable.
 
> I'm not sure why you are drawing some of the distinctions you do.  I 
> have never seen anyone consider continuous assignments to be 
> "structural" HDL.  Rather complex logic can be defined that way although 
> I think most logic ends up in processes or the equivalent.

OK, it seems that the book I have calls the continuous assignment
form data-flow model.
 
(snip)
>>> Sure, the two are very different.  Behavioral code requires thinking and
>>> analysis.  Structural code is just a matter of wiring together blocks.

>> I consider continuous assignment part of structural, though it might
>> have another name, and some logic goes in there.
 
> I only consider instantiations to be structural.  Continuous assignments 
> have several logical constructs which will infer logic and are often 
> used that way.  It is actually seldom that I use continuous assignments 
> for structure since the connections are made in the component 
> instantiations.  Why would I want to connect two wires with an 
> assignment unless there was something very odd going on like one wire 
> into a module connected to two wires going out?  I don't know I have 
> ever done that.

A lot of my VHDL assignments are putting together or taking apart
vectors.  It seems that VHDL feature is too new. So I have:

y29 <= (a, b, c, d);
-- instantiate entity using y29.

(snip)

>> Some can be written about the same either way.  When I have a
>> choice between verilog continuous assignment and behavioral assignment,
>> I choose the former, others might choose the latter.
 
> Not sure why that matters.  If it generates logic, it is not structural. 
>  I think we have a *big* difference in definitions.  Behavioral does 
> not imply any type of assignment to me.  It is a method of designing 
> logic by describing how the logic works rather than describing how it is 
> constructed.  Both concurrent and sequential coding is used for 
> behavioral design.
 
> Purely structural design would use instantiation only without inference 
> by any statement type other than within the primitive units.

I suppose, but structural plus continuous assignment takes too
long to write.
 
> Of course my designs are never purely behavioral without use of module 
> instantiation.  It is easier to test a design in pieces, then glue the 
> pieces together and test again.  I think our disagreement is how far 
> down the modules are divided.  My typical module size is a couple dozen 
> to a hundred or so lines.  Although the really large ones are the top 
> level gluing it all together with structural code.  One of my smaller 
> top level modules is over 600 lines of glue.  Not hard to get right 
> using the tools that let me copy and paste with regular expression 
> conversions.  Errors creep in when changes are made.

I suppose, but I do know people who write mostly behavioral, 
with one big process block in each entity.
 
>> I usually put registers into their own module, even if that is the
>> only thing in the module.

>> One that I am working on now is exactly taking a design in SSI and
>> MSI and writing it in VHDL. The SSI (gates) go into assignment
>> statements with the appropriate logical operations. MSI (anything
>> more complicated than just gates) into a module. I can verify the
>> operation of the module once, and use it many times.
 
> MSI is a very basic functional block.  If you are using this very often 
> you likely are working at a very low level.
 
> The point is that it is not rocket science to code a shift register or 
> counter.  There is very little value in being able to say you have a 
> verified counter module.  Not much different than saying you have a 
> verified multiplexor module which you say you do in continuous assignments.

If the design is already written in such blocks, it works well.
 
> In the end, using such MSI components can be as error prone as writing 
> them from scratch.  I avoid most errors in behavioral code by pulling up 
> an existing file and copying an arbitrary process for a registered 
> function and then editing the code.  It also reduces the tedium.  Then I 
> can focus on the specifics of what this function needs to do other than 
> be a register.
 
(snip)

>> As far as I know, some people like the way it looks more like a
>> software (sequential) programming language.
 
> Not sure what you mean by this.  Only the guts of processes, procedures 
> and functions look and feel like a sequential language.  I think we may 
> be talking about different things because you include continuous 
> assignments as "structural".

OK, but continuous assignment isn't behavioral either. 

Behavioral has its own assignment.
 
>>> Actually, I realize using structural code at the lower levels would be
>>> *very* verbose because none of the higher level structural code is
>>> reduced.  So writing high and mid-level modules in structural code would
>>> add lots of verbiage.

>> Well, for example, I might write a multiplexer in a module, nice
>> combinatorial logic with no registers, then use that module wherever
>> I need a multiplexer, instead of rewriting one each time.
 
> Yeah, that is the level of design that should be like falling off a log. 
>  It is a one liner in a continuous assignment, five lines in a process 
> with two of them being ELSE and END IF;
 
> Here is an example...
 
>   SineAmpWord <= LUT_Data when ('0' = PhaseSign) else - LUT_Data;
 
> --- or ---
>        if ('0' = PhaseSign) then
>          SineAmpWord   <= LUT_Data;
>        else
>          SineAmpWord   <= - LUT_Data;
>        end if;
 
> A great reason for inferring this logic is because the tools may decide 
> to skip the mux and use an adder with one input being a N bit bus of the 
> control signal saving a bunch of logic.  If I hardwired it as a mux it 
> would not be as efficient and coding it this way I don't have to think 
> about it.  Then again the tools would likely optimize it either way. lol

The tools are pretty good. Sometimes a small mistake and half the
logic gets optimized away. 
 
>> Internally, that module will use either the verilog conditional
>> operator or VHDL WHEN operator. (Being use to C, I find the WHEN
>> syntax a little strange, but it doesn't take long to get used to.)

>> I suspect others will build a multiplexer using behavioral if
>> statements in either language.

>> OK, here is a multiplexer in VHDL:

>> library IEEE;
>> use IEEE.std_logic_1164.all;

>> entity N157 is
>>    port (
>>      Y : out std_logic_vector(3 downto 0);
>>      A, B : in std_logic_vector(3 downto 0);
>>      S, G: std_logic);
>> end entity N157;

>> architecture N157 of N157 is
>> begin
>>     Y <= X"0" when G='1' else A when S='0' else B;
>> end architecture N157;
 
> This is a terrible multiplexor module in VHDL.  It is exactly 4 bits 
> wide when it could have been made N bits wide.  Also it only works for 
> SLV data type when the example I use above will work for any types 
> available.  BTW, what's with the name N157?  

It is the logic of the 74157. 

> Wouldn't it be better to 
> use something more descriptive?  Otherwise, notice that all the work is 
> done in one line.  Why go to all the trouble of the above when you only 
> need the one line?
 
> Here is an example of a 5 to 1 mux by instantiation from a VHDL lecture.
 
> --5:1 mux, 1 bit wide
> LIBRARY ieee;
> USE ieee.std_logic_1164.ALL;
> LIBRARY adk;
> USE adk.all;
> ENTITY mux5_1_1wide IS
>   PORT(
>      a_input   : IN STD_LOGIC;  --input a
>      b_input   : IN STD_LOGIC;  --input b
>      c_input   : IN STD_LOGIC;  --input c
>      d_input   : IN STD_LOGIC;  --input d
>      e_input   : IN STD_LOGIC;  --input e
>      sel       : IN STD_LOGIC_VECTOR(2 DOWNTO 0);  --sel input
>      z_out     : OUT STD_LOGIC  --data out
>      );
> END mux5_1_1wide;
> ARCHITECTURE beh OF mux5_1_1wide IS
>   SIGNAL temp0, temp1, temp2, temp3 : STD_LOGIC;
>   COMPONENT mux21 PORT( a0,a1,s0 : IN  STD_LOGIC;
>                                y : OUT STD_LOGIC);  END COMPONENT;
>   COMPONENT inv01 PORT(  a : IN  STD_LOGIC;
>                          y : OUT STD_LOGIC);  END COMPONENT;
>   BEGIN
>   U1 : mux21 PORT MAP(a0  => a_input,
>                       a1  => b_input,
>                       s0  => sel(0),
>                        y  => temp0);
>   U2 : mux21 PORT MAP(a0  => c_input,
>                       a1  => d_input,
>                       s0  => sel(0),
>                        y  => temp1);
>   U3 : mux21 PORT MAP(a0  => temp0,
>                       a1  => temp1,
>                       s0  => sel(1),
>                        y  => temp2);
>   U4 : mux21 PORT MAP(a0  => temp2,
>                       a1  => e_input,
>                       s0  => sel(2),
>                        y  => temp3);
>   U5 : inv01  PORT MAP(a   => temp3,
>                        y   => z_out);
>  END beh;
> 
> Using behavioral descriptions.
> 
> --5:1 mux, 1 bit wide
> LIBRARY ieee;
> USE ieee.std_logic_1164.ALL;
> LIBRARY adk;
> USE adk.all;
> ENTITY mux5_1_1wide IS
> PORT(
> a_input : IN STD_LOGIC; --input a
> b_input : IN STD_LOGIC; --input b
> c_input : IN STD_LOGIC; --input c
> d_input : IN STD_LOGIC; --input d
> e_input : IN STD_LOGIC; --input e
> sel : IN STD_LOGIC_VECTOR(2 DOWNTO 0); --sel input
> z_out : OUT STD_LOGIC --data out
> );
> END mux5_1_1wide;
> ARCHITECTURE beh OF mux5_1_1wide IS
>  BEGIN
>    with sel select z_out <=
>       a_input when 0, -- count/2 = 1 for this choice
>       b_input when 1,
>       c_input when 2,
>       d_input when 3,
>       e_input when others;
>  END beh;
 
> Which is simpler and more clear?  

If the logic is already written using such blocks, it is much easier
to write VHDL from those blocks, and then verify that they look
like the original design.

> If you were coding something more 
> complex, would you really want to code it by assembling pieces rather 
> than just describing what it does?  I had to use the schematic produced 
> by synthesis to see what was done in the case of sel > 4 so I could code 
> the behavioral logic the same.

Also, as well as I know it, that isn't behavioral. 

For behavioral verilog it would look something like:

always @(*) begin
   if (sel=0) then z_out <= a_input
   else if (sel=1) then z_out <= b_input
   else if (sel=2) then z_out <= c_input
   else if (sel=3) then z_out <= d_input
   else z_out <= e_input;
end

or I suppose the verilog case statement.

The non-behavioral verilog form is:

assign zout <= sel=0 ? a_input :
               sel=1 ? b_input :
               sel=2 ? c_input :
               sel=3 ? d_input :
               e_input :

(snip)

>> If it fits reasonably, I put a whole module/entity instatiation
>> on one line. I stay within 80 characters (for one, so that they print
>> nicely), so some will take more lines. Maybe that is from using
>> verilog first.
 
> To do that you need to use positional association which is error prone. 
>  Not a big deal for small entities, but harder to get right for large 
> ones with lots of I/O.  I *always* use named association to prevent 
> difficult to find errors.
 
>>> Still, I think the high and mid-level modules will become rather verbose
>>> with structural code.

>> My early verilog was systolic arrays, with repeated blocks of fairly
>> simple code. The mid-level module fit on one or two pages, matching
>> fairly closely the register transfer logic that one might write.
>> Lower level were registers, adders, comparators, and multiplexers.
>> Top level instantiated some number of the unit cell in a linear array.
 
> There will be some designs that suit instantiation well.  I remember a 
> frequent poster here with a company specializing in high speed design in 
> Xilinx devices.  He used hierarchical schematic design since it gave him 
> complete control over both the logic and placement via attributes 
> attached to the various symbols.  When the rest of the world was moving 
> to HDL, he resisted until he was shown how he could do exactly the same 
> things in VHDL.  He never looked back.  Clearly structural HDL was the 
> way to go for him.

-- glen



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search