Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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. -- RickArticle: 158176
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.comArticle: 158177
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@murrayhyphenmicroftdotcodotukArticle: 158178
> 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 SvennArticle: 158179
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-2Article: 158180
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
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). -- RickArticle: 158182
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. -- glenArticle: 158183
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
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? -- RickArticle: 158185
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, BobHArticle: 158186
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. -- glenArticle: 158187
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. -- glenArticle: 158188
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 BharathArticle: 158189
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. -- RickArticle: 158190
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. -- RickArticle: 158191
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
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. -- glenArticle: 158193
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. -- RickArticle: 158194
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.comArticle: 158195
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
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: 158197Tim 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. -- glenArticle: 158198
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
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:
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