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 30/01/2020 01:29, Rick C wrote: > On Wednesday, January 29, 2020 at 8:07:01 PM UTC-5, Theo wrote: >> Jon Elson <elson@pico-systems.com> wrote: >>> On Mon, 27 Jan 2020 10:28:39 -0800, ritchiew wrote: >>> >>>> On Monday, February 20, 2006 at 1:50:15 PM UTC-8, James Morrison wrote: >>>>> On Mon, 2006-02-20 at 10:18 -0800, Marko wrote: >>>>>> Traditionally, firmware was defined as software that resided in ROM. >>>>>> So, my question is, what do you call FPGA code? Is "firmware" >>>>>> appropriate? >>> The FPGA manufacturers call it the "configuration", but I don't think >>> firmware is very wrong when talking to less-technical folks. >> >> I'm uncomfortable with the use of 'firmware', because FPGAs frequently have >> some kind of processors on them, either soft cores or hard cores like the >> ARM on a Zynq. Those cores run a software stack - either bare metal, some >> RTOS or maybe Linux. There's quite a difference between the software >> running on these cores and the hardware design programmed into the FPGA. >> Typically when one refers to an embedded product 'firmware' is referring to >> software for a processor. If you advertise for FPGA firmware engineers you >> might expect software people to apply for the job, for instance. >> >> Another term used for the hardware is 'bitstream' - not very descriptive, >> although it does imply the hardware-blockbox overtones to it. >> >> If you're talking in general terms about the lump of data loaded from flash >> on boot, used to make the product usable, without any distinction of whether >> it's hardware or software, then maybe firmware works slightly better. >> >> Theo > > I guess my interest is in a label for the program as written in the language, the HDL. I don't call that a bitstream. The bitstream is what gets loaded into the FPGA. I write software or firmware. I've never gotten used to the term "gateware" but it would be fine if that is what ends up being accepted ultimately. Interesting question. You write a hardware description language so what you produce must be the "Hardware description"... I personally am quite happy to call the HDL source code an "Program" or an "hdl program". A "program" really is just a list of instructions. Just as "g-code" is a programming language used to control a 3-d printer or milling. machine, VHDL is a programming language that is used to "program" a "logic synthesisers" which generates the bitstream. > > Rather than to say, this term means this and that term means that, I would ask what the purpose of using those terms would be? What distinction is being made? > Generally we use the term "firmware" to refer to code that is in some way an intrinsic part of the hardware, without which it won't function. DaveArticle: 161626
On Thursday, January 30, 2020 at 4:31:29 AM UTC-5, David Wade wrote: > On 30/01/2020 01:29, Rick C wrote: > > On Wednesday, January 29, 2020 at 8:07:01 PM UTC-5, Theo wrote: > >> > >> If you're talking in general terms about the lump of data loaded from = flash > >> on boot, used to make the product usable, without any distinction of w= hether > >> it's hardware or software, then maybe firmware works slightly better. > >> > >> Theo > >=20 > > I guess my interest is in a label for the program as written in the lan= guage, the HDL. I don't call that a bitstream. The bitstream is what gets= loaded into the FPGA. I write software or firmware. I've never gotten us= ed to the term "gateware" but it would be fine if that is what ends up bein= g accepted ultimately. >=20 > Interesting question. You write a hardware description language so what= =20 > you produce must be the "Hardware description"... The source code is indeed a hardware description. =20 > I personally am quite happy to call the HDL source code an "Program" or= =20 > an "hdl program". >=20 > A "program" really is just a list of instructions. Just as "g-code" is a= =20 > programming language used to control a 3-d printer or milling. machine,= =20 > VHDL is a programming language that is used to "program" a "logic=20 > synthesisers" which generates the bitstream. >=20 >=20 > >=20 > > Rather than to say, this term means this and that term means that, I wo= uld ask what the purpose of using those terms would be? What distinction i= s being made? > >=20 >=20 > Generally we use the term "firmware" to refer to code that is in some=20 > way an intrinsic part of the hardware, without which it won't function. My PC won't function without software. So what is really different? Origi= nally it had to do with the fact that firmware resided in ROM or EPROM whic= h could only be programmed by means other than just loading it into RAM. = =20 Now with Flash memory being rewritable in the system, there is much less di= stinction and in many systems the Flash acts more like a hard drive with th= e program being executed from RAM. Raspberry Pi devices are like that. Ev= erything about developing code for a rPi is like developing code for a PC, = but in the end it is an embedded system. =20 So what would be the purpose of calling this firmware... or any other devic= e?=20 --=20 Rick C. -+ Get 1,000 miles of free Supercharging -+ Tesla referral code - https://ts.la/richard11209Article: 161627
In article <6b78649f-b7f1-42d8-bb78-c1431b762072@googlegroups.com>, Rick C <gnuarm.deletethisbit@gmail.com> wrote: >On Wednesday, January 29, 2020 at 7:28:18 PM UTC-5, gtwrek wrote: >> In article <7d2a4342-3444-435c-a73b-9e130834212f@googlegroups.com>, >> Rick C <gnuarm.deletethisbit@gmail.com> wrote: >> > >> >Firmware is as good as any term. I'm ok with calling it software. >> >> "Firmware" is one of those terms that has a very specific meaning in a >> very specific context. And means exactly what it is intended to mean. >> But as soon as the context changes... So does the definition. >> >> Which makes the term practically useless as a general use technical >> description. Sure for the general public, (or anything above a level 2 >> manager), "Firmware" might as well mean "The magic smoke which makes my >> device do things when I turn it on". Usually one thinks of it as >> applying to "embedded" electronic devices - which is another fuzzy >> definition in itself. Here, "Embedded" usually means any device that's >> not a personal computer sitting on one's desk. But even that's up >> for argument... > >So what is that very specific meaning of "firmware"??? I've not come across it. Every source I check has a different wording and meaning. > >Wikipedia - In computing, firmware[a] is a specific class of computer software that provides the low-level control for the device's specific hardware. > >Google - permanent software programmed into a read-only memory. > >techterms.com - Firmware is a software program or set of instructions programmed on a hardware device. It provides the necessary instructions for how the device communicates with the other computer hardware. > >lifewire.com - Firmware is software that's embedded in a piece of hardware > >So each one is different enough that the included classes vary hugely! > >What is yours? That's my point. My definition entirely depends on context. So much so that as a general term "firmware" is next to useless in a general technical forum... Regards, MarkArticle: 161628
In article <r0u7pd$i5k$1@dont-email.me>, David Wade <g4ugm@dave.invalid> wrote: >Interesting question. You write a hardware description language so what >you produce must be the "Hardware description"... > >I personally am quite happy to call the HDL source code an "Program" or >an "hdl program". > >A "program" really is just a list of instructions. Just as "g-code" is a >programming language used to control a 3-d printer or milling. machine, >VHDL is a programming language that is used to "program" a "logic >synthesisers" which generates the bitstream. Not trying to dig or start a flame here... But when I hear someone describe Verilog or VHDL as a "program", I'm almost certain to (prejudge) that such individual is a newbie, or inexperienced at FPGA design. Thinking of traditional "programs" or "list of instructions" when designing an FPGA is certainly the wrong mindset. FPGA vendors would love to think that there new wonderful C like "High level languages" are just super programs that make things run fast on an FPGA. But they're nothing of the sort. One "designs" with an HDL akin to how one designs with a schematic. Comparing to instruction based CPU's just doesn't fit, which is (in my mind) what "programs" traditionally do. My 2cents. Regards, MarkArticle: 161629
On Thursday, January 30, 2020 at 2:23:26 PM UTC-5, gtwrek wrote: > In article <6b78649f-b7f1-42d8-bb78-c1431b762072@googlegroups.com>, > Rick C <gnuarm.deletethisbit@gmail.com> wrote: > >On Wednesday, January 29, 2020 at 7:28:18 PM UTC-5, gtwrek wrote: > >> In article <7d2a4342-3444-435c-a73b-9e130834212f@googlegroups.com>, > >> Rick C <gnuarm.deletethisbit@gmail.com> wrote: > >> > > >> >Firmware is as good as any term. I'm ok with calling it software. = =20 > >>=20 > >> "Firmware" is one of those terms that has a very specific meaning in a > >> very specific context. And means exactly what it is intended to mean. > >> But as soon as the context changes... So does the definition. > >>=20 > >> Which makes the term practically useless as a general use technical > >> description. Sure for the general public, (or anything above a level = 2 > >> manager), "Firmware" might as well mean "The magic smoke which makes m= y > >> device do things when I turn it on". Usually one thinks of it as > >> applying to "embedded" electronic devices - which is another fuzzy > >> definition in itself. Here, "Embedded" usually means any device that'= s > >> not a personal computer sitting on one's desk. But even that's up > >> for argument... > > > >So what is that very specific meaning of "firmware"??? I've not come ac= ross it. Every source I check has a different wording and meaning.=20 > > > >Wikipedia - In computing, firmware[a] is a specific class of computer so= ftware that provides the low-level control for the device's specific hardwa= re.=20 > > > >Google - permanent software programmed into a read-only memory. > > > >techterms.com - Firmware is a software program or set of instructions pr= ogrammed on a hardware device. It provides the necessary instructions for h= ow the device communicates with the other computer hardware. > > > >lifewire.com - Firmware is software that's embedded in a piece of hardwa= re > > > >So each one is different enough that the included classes vary hugely! = =20 > > > >What is yours?=20 >=20 > That's my point. My definition entirely depends on context. So much so > that as a general term "firmware" is next to useless in a general > technical forum... Yeah, I think I misread your other post. I agree. It's like Humpty Dumpty= said,=20 =E2=80=9CWhen I use a word,=E2=80=9D Humpty Dumpty said, in rather a scornf= ul tone, =E2=80=9Cit means just what I choose it to mean=E2=80=94neither mo= re nor less.=E2=80=9D --=20 Rick C. +- Get 1,000 miles of free Supercharging +- Tesla referral code - https://ts.la/richard11209Article: 161630
On 30/01/2020 19:34, gtwrek wrote: > In article <r0u7pd$i5k$1@dont-email.me>, > David Wade <g4ugm@dave.invalid> wrote: >> Interesting question. You write a hardware description language so what >> you produce must be the "Hardware description"... >> >> I personally am quite happy to call the HDL source code an "Program" or >> an "hdl program". >> >> A "program" really is just a list of instructions. Just as "g-code" is a >> programming language used to control a 3-d printer or milling. machine, >> VHDL is a programming language that is used to "program" a "logic >> synthesisers" which generates the bitstream. > > Not trying to dig or start a flame here... But when I hear someone > describe Verilog or VHDL as a "program", I'm almost certain to > (prejudge) that such individual is a newbie, or inexperienced at FPGA > design. Thinking of traditional "programs" or "list of instructions" when > designing an FPGA is certainly the wrong mindset. > > FPGA vendors would love to think that there new wonderful C like "High > level languages" are just super programs that make things run fast on an > FPGA. But they're nothing of the sort. One "designs" with an HDL akin > to how one designs with a schematic. > correct. > Comparing to instruction based CPU's just doesn't fit, which is (in my > mind) what "programs" traditionally do. > Thats what typical modern programs do. But that is a very narrow use of the word "program" Those of us who are old enough to have programmed an analog computer may recall that we did so by physically wiring analog adders, integrators, comparators and other components together. In fact using a very similar process to that we use to configure an FPGA. Going back to Eniac that was also "programmed" with wires and plug boards. so whilst many folks assume a "program" is restricted to digitl languages, historially it was applied to other processes.. > My 2cents. > > Regards, > Mark > > > DaveArticle: 161631
In article <r11iid$ofc$1@dont-email.me>, David Wade <g4ugm@dave.invalid> wrote: >Thats what typical modern programs do. But that is a very narrow use of >the word "program" Those of us who are old enough to have programmed >an analog computer may recall that we did so by physically wiring analog >adders, integrators, comparators and other components together. > >In fact using a very similar process to that we use to configure an FPGA. > >Going back to Eniac that was also "programmed" with wires and plug boards. > >so whilst many folks assume a "program" is restricted to digitl >languages, historially it was applied to other processes.. It's no longer the canonical definition in my opinion. When I hear a question on some FPGA group asking about some details on "my verilog program" it's inevitably a newbie with a software background. While I've never touch an Eniac - nor seen one outside a musuem - I've debugged a few wire-wrapped systems in my career early days. Don't care to go back to that... Regards, MarkArticle: 161632
On 31/01/2020 17:53, gtwrek wrote: > In article <r11iid$ofc$1@dont-email.me>, > David Wade <g4ugm@dave.invalid> wrote: >> Thats what typical modern programs do. But that is a very narrow use of >> the word "program" Those of us who are old enough to have programmed >> an analog computer may recall that we did so by physically wiring analog >> adders, integrators, comparators and other components together. >> >> In fact using a very similar process to that we use to configure an FPGA. >> >> Going back to Eniac that was also "programmed" with wires and plug boards. >> >> so whilst many folks assume a "program" is restricted to digitl >> languages, historially it was applied to other processes.. > > It's no longer the canonical definition in my opinion. When I hear a > question on some FPGA group asking about some details on "my verilog > program" it's inevitably a newbie with a software background. > So what do experienced folks say? Simply "My VHDL" or "my verilog" I guess? Perhaps the issue is with the training materials. Most of the VHDL tutorials I can find refer to VHDL programming and I don't see how you can have programming without a program. I must admit I it took me a while to get my head round the non-sequential behaviour of VHDL and wondered how the tools that claim to let you program FPGAs in "C" work in practice. > While I've never touch an Eniac - nor seen one outside a musuem - I've debugged a few > wire-wrapped systems in my career early days. Don't care to go back to that... > Well most Tuesday I get to demonstrate the replica Manchester Baby/SSEM, a valve/tube computer but thats really just like a modern machine to the programmer. Inside it has some tweaks to cut down on valves/tubes. But I also own an EAI TR-10 analoge computer which is definitely programmed with wires... (This one isn't mine) http://www.analogmuseum.org/english/collection/eai/tr10/ > Regards, > Mark Dave > > DaveArticle: 161633
On Friday, January 31, 2020 at 10:53:52 AM UTC-5, David Wade wrote: > On 30/01/2020 19:34, gtwrek wrote: > > In article <r0u7pd$i5k$1@dont-email.me>, > > David Wade <g4ugm@dave.invalid> wrote: > >> Interesting question. You write a hardware description language so wha= t > >> you produce must be the "Hardware description"... > >> > >> I personally am quite happy to call the HDL source code an "Program" o= r > >> an "hdl program". > >> > >> A "program" really is just a list of instructions. Just as "g-code" is= a > >> programming language used to control a 3-d printer or milling. machine= , > >> VHDL is a programming language that is used to "program" a "logic > >> synthesisers" which generates the bitstream. > >=20 > > Not trying to dig or start a flame here... But when I hear someone > > describe Verilog or VHDL as a "program", I'm almost certain to > > (prejudge) that such individual is a newbie, or inexperienced at FPGA > > design. Thinking of traditional "programs" or "list of instructions" w= hen > > designing an FPGA is certainly the wrong mindset. > >=20 > > FPGA vendors would love to think that there new wonderful C like "High > > level languages" are just super programs that make things run fast on a= n > > FPGA. But they're nothing of the sort. One "designs" with an HDL akin > > to how one designs with a schematic. > >=20 >=20 > correct. While I tend to think in terms of the logic involved and write my HDL to de= scribe the logic I have in mind, not everyone works that way (many call thi= s RTL coding). =20 Once I was interviewing for a job and when asked I described this method of= designing. The lead engineer of a Japanese team disagreed saying they did= n't have time to optimize the code so they wrote to describe the behavior i= nstead (many call this behavioral coding). I was trying to point out that = the two do not need to be in conflict, that an RTL coding style can be used= to describe behavior with little or no additional effort. The lead engine= er disagreed and we discussed it a little. When I was in touch with the re= cruiter he asked me about the "confrontation"! I didn't realize there was = a confrontation. lol Obviously there was not a good match of cultures.=20 > > Comparing to instruction based CPU's just doesn't fit, which is (in my > > mind) what "programs" traditionally do. > >=20 >=20 > Thats what typical modern programs do. But that is a very narrow use of= =20 > the word "program" Those of us who are old enough to have programmed > an analog computer may recall that we did so by physically wiring analog= =20 > adders, integrators, comparators and other components together. >=20 > In fact using a very similar process to that we use to configure an FPGA. >=20 > Going back to Eniac that was also "programmed" with wires and plug boards= . >=20 > so whilst many folks assume a "program" is restricted to digitl=20 > languages, historially it was applied to other processes.. Yes, I wish there were better terms to describe programs written to run on = sequential processors to distinguish them from programs written to describe= hardware. The emphasis these days is to try to merge the two so the entir= e application can be written in one language and different layers can be im= plemented in either domain as best suits the particulars of the system bein= g designed.=20 Just some thoughts... --=20 Rick C. ++ Get 1,000 miles of free Supercharging ++ Tesla referral code - https://ts.la/richard11209Article: 161634
On 02/01/20 11:25, Rick C wrote: > While I tend to think in terms of the logic involved and write my HDL > to describe the logic I have in mind, not everyone works that way > (many call this RTL coding). I have a computer engineering degree, but I've spent most of my professional career writing software for embedded CPUs (with a bit of hardware designed on the side). So, I'm probably tainted in this respect. I agree with your statement, Rick. A grumpy old FGPA engineer once told me that anyone who says they're "writing a program for an FPGA" doesn't know what they're doing. He says they typically end up with a design which is not synthesizable. He and I agree on this point. You're describing how you're hooking up logic within the FPGA, virtually connecting the wires between logic gates. HDLs let you cheat a bit and say what you want to do, then they try to figure out what you meant. This elaboration process can be perilous, if one does not know the proper incantations. The older HDLs, such as PALASM and CUPL were so close to wiring gates together that it was painful, but they didn't infer much, if anything, about what you meant. So, here's my nomenclature: "Software" -> Stored program code, typically stored in offline memory and then loaded into RAM to run on a CPU. Also a generic term, even if applied to embedded systems. "Firmware" -> Stored program code, residing in Flash/EPROM/EEPROM/etc. and ready for instant fetch/execute by a CPU. "Program" -> Noun: Source code for Firmware or Software, Verb: The physical act of putting bits into some storage, usually Flash/EPROM/... "RTL" or "Design" -> The embodiment of a Boolean logic design, typically in the form of a Hardware Design Language such as Verilog, VHDL, etc. "Bitstream" or "Configuration" -> When the RTL/Design is fed into a design tool that compiles/elaborates/synthesizes the former, along with a description of the target hardware, into a series of bits or bytes in a file. This file, when loaded into the FPGA, configures the gates/LUTs/other-logic-elements into the hardware design described by the RTL/Design. Anyway, if one stays away from the terms "Software" or "Firmware" for hardware design and remembers that FPGAs are just a sea of look-up tables and logic, one won't fall into the trap of thinking that stuff at the top of the HDL source file executes before the stuff at the bottom. --- ZachArticle: 161635
On Sunday, February 2, 2020 at 8:09:09 PM UTC-5, Zach Metzinger wrote: > On 02/01/20 11:25, Rick C wrote: > > While I tend to think in terms of the logic involved and write my HDL > > to describe the logic I have in mind, not everyone works that way > > (many call this RTL coding). >=20 > I have a computer engineering degree, but I've spent most of my=20 > professional career writing software for embedded CPUs (with a bit of=20 > hardware designed on the side). So, I'm probably tainted in this respect. I started with electronic hardware when I was a young teenager with a hand = wired kit/toy with bells, lights, switches and batteries. I call it "elect= ronic" because I learned to gang SPST switches together to make DPDT switch= es, my first logic exercise. lol From then on it was all a direct path.= =20 So I'm probably "tainted" too. =20 > I agree with your statement, Rick.=20 That's always a great way to start a discussion even if you disagree. A f= riend makes a point of telling me every time I see him, "You are not only r= ight, you are absolutely correct". Lol... so far it hasn't completely take= n, I tend to be a bit argumentative online.=20 > A grumpy old FGPA engineer once told=20 > me that anyone who says they're "writing a program for an FPGA" doesn't= =20 > know what they're doing. He says they typically end up with a design=20 > which is not synthesizable. He and I agree on this point. Your friend was not only right, but absolutely correct... except for the pa= rt about then not knowing what they are doing. I call it a program, but us= ually add "code" as in "I'm working on the program code now". While proces= sor code is written differently most of the time, they are both still actua= lly not totally different. Just don't confuse a process sensitivity list f= or a subroutine parameter list. =20 > You're describing how you're hooking up logic within the FPGA, virtually= =20 > connecting the wires between logic gates.=20 That would be true of instantiated logic which I typically use at the modul= e level, but not true of the logic defined in the modules. Inside the modu= les the logic is simply described in the assignment expressions. It is ent= irely up to the synthesis tool to synthesize the logic and it's up to the b= ack end tools to place and route. My code has nothing/little to do with th= e P&R unless I add very detailed instructions which are vendor unique and v= ery laborious.=20 > HDLs let you cheat a bit and=20 > say what you want to do, then they try to figure out what you meant.=20 Not so much "try to figure out" since logic is a well defined part of the l= anguage. The synthesis tool tries to provide an optimal solution. In one,= not unusual case I recall getting poor results because my code was not des= cribing what I was seeing in my head like I thought it was. So instead of = getting an optimized structure, I was duplicating the adder chain to get th= e carry out. My coding style learned from that. Now I code the logic of s= uch adders/counters outside the process so there will only ever be one adde= r/carry chain and use the results of that adder in the process. I suppose = if I were more organized, I could make the adder logic a library function r= esulting in a single, simple, consistent line of code where used.=20 > This elaboration process can be perilous, if one does not know the=20 > proper incantations. The older HDLs, such as PALASM and CUPL were so=20 > close to wiring gates together that it was painful, but they didn't=20 > infer much, if anything, about what you meant. Not sure I'd call PALASM or CUPL HDLs. I suppose it is, but they're more l= ike assemblers for logic than high level languages.=20 > So, here's my nomenclature: >=20 > "Software" -> Stored program code, typically stored in offline memory=20 > and then loaded into RAM to run on a CPU. Also a generic term, even if=20 > applied to embedded systems. >=20 > "Firmware" -> Stored program code, residing in Flash/EPROM/EEPROM/etc.=20 > and ready for instant fetch/execute by a CPU. You are not only right, but absolutely correct! So what exactly is the dif= ference between reading a program from a flash drive into ram for execution= and loading a program from a flash chip into ram for execution? Does a Ra= spberry Pi built into a box to control lighting in a house load software fr= om it's SD card or load firmware? If the same job is being done by a TI MS= P430 does it load software or firmware from the internal Flash on the chip?= What if either of these devices are connected to a rotating disk for prog= ram storage?=20 Or are you saying firmware has to be in Flash that can be directly addresse= d and executed by the CPU?=20 This is what I mean by there not being much value in even distinguishing th= e terms. To me it's more of a "who cares" about using one term or the othe= r since the boundary is so subjective and not of much value. What does cal= ling it software imply that firmware doesn't or vice versa?=20 > "Program" -> Noun: Source code for Firmware or Software, Verb: The=20 > physical act of putting bits into some storage, usually Flash/EPROM/... >=20 > "RTL" or "Design" -> The embodiment of a Boolean logic design, typically= =20 > in the form of a Hardware Design Language such as Verilog, VHDL, etc. What does it mean to you to say "Boolean logic" exactly? Don't most comput= er programs utilize Boolean logic in one way or the other, the same as HDL.= =20 A <=3D B + C;=20 Is this RTL or software or what exactly? Is this different?=20 A =3D B + C; > "Bitstream" or "Configuration" -> When the RTL/Design is fed into a=20 > design tool that compiles/elaborates/synthesizes the former, along with= =20 > a description of the target hardware, into a series of bits or bytes in= =20 > a file. This file, when loaded into the FPGA, configures the=20 > gates/LUTs/other-logic-elements into the hardware design described by=20 > the RTL/Design. >=20 > Anyway, if one stays away from the terms "Software" or "Firmware" for=20 > hardware design and remembers that FPGAs are just a sea of look-up=20 > tables and logic, one won't fall into the trap of thinking that stuff at= =20 > the top of the HDL source file executes before the stuff at the bottom. That's a very fundamental difference that has to be understood before doing= any HDL work. I took a 1 week class in VHDL and they didn't do that. The= instructor just followed a book that wasn't really so good and he seemed i= ncapable of making that distinction of everything at the top level (concurr= ent code) was running in parallel rather than sequential. He also failed t= o explain that a process was not a subroutine in any way that helped. (Jus= t saying they aren't the same doesn't really help) The biggest issue is th= at the sensitivity list is not a parameter list. Then there is the fact th= at outside a process the code is parallel, inside the code is sequential. = Nope, no real explanation of that. The guy had no business teaching the st= uff.=20 Anyway, I find it interesting to discuss experiences. I haven't done any c= oding in a while. =20 --=20 Rick C. --- Get 1,000 miles of free Supercharging --- Tesla referral code - https://ts.la/richard11209Article: 161636
On 2020-02-02 23:32, Rick C wrote: > Your friend was not only right, but absolutely correct... except for > the part about then not knowing what they are doing. I call it a > program, but usually add "code" as in "I'm working on the program > code now". While processor code is written differently most of the > time, they are both still actually not totally different. Just don't > confuse a process sensitivity list for a subroutine parameter list. :-D > Not sure I'd call PALASM or CUPL HDLs. I suppose it is, but they're > more like assemblers for logic than high level languages. They're definitely more limited, to be sure. But CUPL does have syntax for truth tables, state machines, etc. > Or are you saying firmware has to be in Flash that can be directly > addressed and executed by the CPU? Yes, this is what I'd consider the turning point for "firmware". Something that is instantly available for execution, without being first loaded by some other mechanism (ROM, 1st/2nd stage bootstrap, etc.) >> "RTL" or "Design" -> The embodiment of a Boolean logic design, >> typically in the form of a Hardware Design Language such as >> Verilog, VHDL, etc. > > What does it mean to you to say "Boolean logic" exactly? Don't most > computer programs utilize Boolean logic in one way or the other, the > same as HDL. You are correct. Perhaps the best thing is to delete "Boolean logic" out of that sentence and replace it with "hardware". > A <= B + C; > > Is this RTL or software or what exactly? Is this different? > > A = B + C; Well, one is a nonblocking assignment and one is a blocking assignment, but that's a bit off our topic. :-) > I took a 1 week class in VHDL and they didn't do that. I know very little VHDL, other than my impression that it is more akin to the rigidness of Ada or Pascal, whereas Verilog is closer to anything-goes C. --- ZachArticle: 161637
On Tuesday, February 4, 2020 at 12:39:38 PM UTC-5, Zach Metzinger wrote: > On 2020-02-02 23:32, Rick C wrote: > > Your friend was not only right, but absolutely correct... except for > > the part about then not knowing what they are doing. I call it a > > program, but usually add "code" as in "I'm working on the program > > code now". While processor code is written differently most of the > > time, they are both still actually not totally different. Just don't > > confuse a process sensitivity list for a subroutine parameter list. >=20 > :-D >=20 > > Not sure I'd call PALASM or CUPL HDLs. I suppose it is, but they're > > more like assemblers for logic than high level languages. >=20 > They're definitely more limited, to be sure. But CUPL does have syntax > for truth tables, state machines, etc. Yes, nothing more than just direct logic of one output at a time is allowed= . There isn't much in the way of optimization. No conditional constructs = (the sort of stuff that makes sense to humans and not just totally geek eng= ineers like me). No complexity of assignments. If you want an output to b= e tristate, you don't assign a tristate value to the output, you manipulate= the tristate control of the output. No targets other than simple devices.= =20 Although I shouldn't say this about CUPL as I have not used it.=20 > > Or are you saying firmware has to be in Flash that can be directly > > addressed and executed by the CPU? >=20 > Yes, this is what I'd consider the turning point for "firmware". > Something that is instantly available for execution, without being first > loaded by some other mechanism (ROM, 1st/2nd stage bootstrap, etc.) Ok, so at least you have your clear definition of "embedded". Others inclu= de devices on external properties like the form factor or application. I g= uess my point is everyone having their own definition of the term makes it = hard to have discussions with this language.=20 > >> "RTL" or "Design" -> The embodiment of a Boolean logic design, > >> typically in the form of a Hardware Design Language such as > >> Verilog, VHDL, etc. > >=20 > > What does it mean to you to say "Boolean logic" exactly? Don't most > > computer programs utilize Boolean logic in one way or the other, the > > same as HDL. >=20 > You are correct. Perhaps the best thing is to delete "Boolean logic" out > of that sentence and replace it with "hardware". Ok, but my point is that includes virtually every type of HDL program... er= , design. Conventionally RTL is a coding style that directly specifies reg= isters and the logic between them rather than a functional description that= is more abstract in a way that allows the registers to be less obvious.=20 > > A <=3D B + C; > >=20 > > Is this RTL or software or what exactly? Is this different? > >=20 > > A =3D B + C; >=20 > Well, one is a nonblocking assignment and one is a blocking assignment, > but that's a bit off our topic. :-) That isn't want I intended to be saying. The latter is how you write an as= signment in C. I guess my point is that both types of language have simila= r functionality in many ways... more similarities than differences.=20 > > I took a 1 week class in VHDL and they didn't do that. >=20 > I know very little VHDL, other than my impression that it is more akin > to the rigidness of Ada or Pascal, whereas Verilog is closer to > anything-goes C. Yes, they have relaxed some of the stricter issues such as allowing "IF sig= nal_a THEN" rather than requiring "IF signal_a =3D '1' THEN". But type che= cking is still pretty stiff. At one time a string constant (the way you sp= ecify a vector) had to be type cast as the logic type you wanted because it= can be more than one type. They did something to relax that a couple of r= evisions ago. Still, strong typing can trip up a newbie. You quickly get = used to it. Just think what you intend and if what you write can be interp= reted more than one way. VHDL will not assume. That's the basis of its ri= gor. No assumptions. Verilog has many default assumptions which you have = to know about to not get it wrong by not specifying that you want something= different. It's easy to make a mistake doing math that is hard to find. = =20 --=20 Rick C. --+ Get 1,000 miles of free Supercharging --+ Tesla referral code - https://ts.la/richard11209Article: 161638
hello, is there any way to suppress assertion warnings from std.numeric in gtkwave simulator? thank youArticle: 161639
I read the command line options in the manual and it doesn't seem like it is possible to suppress messages.Article: 161640
On Thu, 6 Feb 2020 23:32:50 -0800 (PST) the clever Bit <hex7c3@gmail.com> wrote: > I read the command line options in the manual and it doesn't seem like it is possible to suppress messages. Have you tried running the build process without gtkwave included?Article: 161641
On Friday, February 7, 2020 at 10:38:12 AM UTC, Jan Coombs wrote: > > Have you tried running the build process without gtkwave > included? good catch. The warning messages appear on simulation with GHDL not gtkwave. I silenced it with --ieee-asserts=disable-at-0.Article: 161642
Hi, I'm trying to program a TinyFPGA BX to provide 3 registers to emulate an FDC9266, the bulk will later be done using an ATMega ucontroller. To sort out the A0,nCS,nRD,nWR,nDACK, I have inserted a code block which should generate the following internal signals: SEL: switch a "Mux 2:1" between the outputs of the STATUS and the DATA IN registers OE: enable a TRI-STATE output to the processor's data bus DW: clock data into the DATA IN register if (nCS == 0 || nDACK == 0) // chip selected begin SEL = A0; // (1) OE = not nRD; // (2) DW = not nWR; // (3) end I keep getting errors "Invalid module instantiation" on lines (1), (2) , and (3) and "Syntax error" on line (1). I cannot find a suitable syntax description, so I tried * "<=" rather than "=" * if (A0 == 1) SEL = 1; else SEL = 0; but the error does not go away. Anyone know how to fix this? Thanks, JosefArticle: 161643
On 13.02.20 10:43, Josef Moellers wrote: > Hi, > > I'm trying to program a TinyFPGA BX to provide 3 registers to emulate an > FDC9266, the bulk will later be done using an ATMega ucontroller. > > To sort out the A0,nCS,nRD,nWR,nDACK, I have inserted a code block which > should generate the following internal signals: > > SEL: switch a "Mux 2:1" between the outputs of the STATUS and the DATA > IN registers > OE: enable a TRI-STATE output to the processor's data bus > DW: clock data into the DATA IN register > > if (nCS == 0 || nDACK == 0) // chip selected > begin > SEL = A0; // (1) > OE = not nRD; // (2) > DW = not nWR; // (3) > end > > I keep getting errors "Invalid module instantiation" on lines (1), (2) , > and (3) and "Syntax error" on line (1). > I cannot find a suitable syntax description, so I tried > * "<=" rather than "=" > * if (A0 == 1) SEL = 1; else SEL = 0; > but the error does not go away. Apparently 1) I need an "always @(1)" before any code 2) I need to declare the outputs "reg SEL, OE, DW" 3) It's not "not", it's "!" Still, this leaves questions: 1) I used "=", but I have also seen "<=" and both are accepted What's the difference between the two? 2) The "reg" suggests some kind of register/latch. Is this true? I just want the logic gates, no latches! JosefArticle: 161644
On Thursday, February 13, 2020 at 7:06:39 AM UTC-5, Josef Moellers wrote: > On 13.02.20 10:43, Josef Moellers wrote: > > Hi, > >=20 > > I'm trying to program a TinyFPGA BX to provide 3 registers to emulate a= n > > FDC9266, the bulk will later be done using an ATMega ucontroller. > >=20 > > To sort out the A0,nCS,nRD,nWR,nDACK, I have inserted a code block whic= h > > should generate the following internal signals: > >=20 > > SEL: switch a "Mux 2:1" between the outputs of the STATUS and the DATA > > IN registers > > OE: enable a TRI-STATE output to the processor's data bus > > DW: clock data into the DATA IN register > >=20 > > =E2=80=A8if (nCS =3D=3D 0 || nDACK =3D=3D 0) // chip selected > > begin > > SEL =3D A0; // (1) > > OE =3D not nRD; // (2) > > DW =3D not nWR; // (3) > > end > >=20 > > I keep getting errors "Invalid module instantiation" on lines (1), (2) = , > > and (3) and "Syntax error" on line (1). > > I cannot find a suitable syntax description, so I tried > > * "<=3D" rather than "=3D" > > * if (A0 =3D=3D 1) SEL =3D 1; else SEL =3D 0; > > but the error does not go away. >=20 > Apparently > 1) I need an "always @(1)" before any code > 2) I need to declare the outputs "reg SEL, OE, DW" > 3) It's not "not", it's "!" >=20 > Still, this leaves questions: > 1) I used "=3D", but I have also seen "<=3D" and both are accepted > What's the difference between the two? > 2) The "reg" suggests some kind of register/latch. > Is this true? I just want the logic gates, no latches! >=20 > Josef You appear to be programming in Verilog which I don't know so well mostly h= aving programmed in VHDL. I don't know that in Verilog assignment statemen= ts always have to be in a process (the always block thing). In VHDL the "t= op level" is to write independent assignment statements which all operate i= n parallel. Then inside a process (slightly different syntax from Verilog = always blocks, it starts with process()) assignment statements are sequenti= al code. =20 To answer your question, there are two types of assignments, blocking and n= on-blocking. The nomenclature has never made sense to me so I don't rememb= er which is which. Looking it up =3D is 'blocking' and <=3D is 'non-blocki= ng'. In VHDL concurrent code always uses <=3D. The blocking vs. non-block= ing only has meaning in sequential code since concurrent code is always exe= cuted in parallel.=20 In a process <=3D means the assignment is done when the code pauses (usuall= y when reaching the end of the process block). So if all assignments in a = process use <=3D nothing is actually assigned until the end of the process = and all are updated with the values on the right hand side of the assignmen= ts at the time they were encountered. The expression is evaluated and save= d, but not assigned to the left hand side until the process stops.=20 In a process an assignment using =3D in Verilog and :=3D in VHDL is made im= mediately so that the value can be changed before reaching the end of the p= rocess. These are only used when you specifically need them for some reaso= n. While they are more like what happens in non-hardware related code, HDL= s mostly are coded with non-blocking assignments using <=3D which does not = work like sequential code in other languages.=20 This is one of several reasons why software coders can't just "pick up" an = HDL language and run with it. They actually need to learn the language and= not assume it works like non-HDLs. Once they come to grips with a few dif= ferences like this, it's not so special and anyone can code in HDLs.=20 --=20 Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209Article: 161645
On 13.02.20 15:43, Rick C wrote: [...] > You appear to be programming in Verilog which I don't know so well mostly having programmed in VHDL. I don't know that in Verilog assignment statements always have to be in a process (the always block thing). In VHDL the "top level" is to write independent assignment statements which all operate in parallel. Then inside a process (slightly different syntax from Verilog always blocks, it starts with process()) assignment statements are sequential code. > > To answer your question, there are two types of assignments, blocking and non-blocking. The nomenclature has never made sense to me so I don't remember which is which. Looking it up = is 'blocking' and <= is 'non-blocking'. In VHDL concurrent code always uses <=. The blocking vs. non-blocking only has meaning in sequential code since concurrent code is always executed in parallel. > > In a process <= means the assignment is done when the code pauses (usually when reaching the end of the process block). So if all assignments in a process use <= nothing is actually assigned until the end of the process and all are updated with the values on the right hand side of the assignments at the time they were encountered. The expression is evaluated and saved, but not assigned to the left hand side until the process stops. > > In a process an assignment using = in Verilog and := in VHDL is made immediately so that the value can be changed before reaching the end of the process. These are only used when you specifically need them for some reason. While they are more like what happens in non-hardware related code, HDLs mostly are coded with non-blocking assignments using <= which does not work like sequential code in other languages. I did find a "Summary of Verilog Syntax in the meantime and, you're (obviously) right: • Blocking assignment Blocking assignments are executed in the order specified in the sequential block, i.e. a blocking assignment waits for previous blocking assignment of the same time to complete before executing. register = expression; • Nonblocking assignment Nonblocking assignments are executed concurrently within the sequential blocks, i.e. a nonblocking assignment executes without waiting for other nonblocking assignments of occurring at the same time to complete. register <= expression; -eoq- > This is one of several reasons why software coders can't just "pick up" an HDL language and run with it. They actually need to learn the language and not assume it works like non-HDLs. Once they come to grips with a few differences like this, it's not so special and anyone can code in HDLs. Yes. I'm actually a software guy who has fiddled around with hardware ever since I left college. A few weeks ago, I leafed through a book in the public library where it said "The main difference between HDL and software programming is that in HDL everything works in parallel". As I'm working in a GUI (usually I'm a command-line-junky), I was only concerned about this code block where I wanted to encapsulate this decoding. Thanks! JosefArticle: 161646
On Thursday, February 13, 2020 at 10:49:01 AM UTC-5, Josef Moellers wrote: > On 13.02.20 15:43, Rick C wrote: > [...] > > You appear to be programming in Verilog which I don't know so well most= ly having programmed in VHDL. I don't know that in Verilog assignment stat= ements always have to be in a process (the always block thing). In VHDL th= e "top level" is to write independent assignment statements which all opera= te in parallel. Then inside a process (slightly different syntax from Veri= log always blocks, it starts with process()) assignment statements are sequ= ential code. =20 > >=20 > > To answer your question, there are two types of assignments, blocking a= nd non-blocking. The nomenclature has never made sense to me so I don't re= member which is which. Looking it up =3D is 'blocking' and <=3D is 'non-bl= ocking'. In VHDL concurrent code always uses <=3D. The blocking vs. non-b= locking only has meaning in sequential code since concurrent code is always= executed in parallel.=20 > >=20 > > In a process <=3D means the assignment is done when the code pauses (us= ually when reaching the end of the process block). So if all assignments i= n a process use <=3D nothing is actually assigned until the end of the proc= ess and all are updated with the values on the right hand side of the assig= nments at the time they were encountered. The expression is evaluated and = saved, but not assigned to the left hand side until the process stops.=20 > >=20 > > In a process an assignment using =3D in Verilog and :=3D in VHDL is mad= e immediately so that the value can be changed before reaching the end of t= he process. These are only used when you specifically need them for some r= eason. While they are more like what happens in non-hardware related code,= HDLs mostly are coded with non-blocking assignments using <=3D which does = not work like sequential code in other languages.=20 >=20 > I did find a "Summary of Verilog Syntax in the meantime and, you're > (obviously) right: > =E2=80=A2 Blocking assignment > Blocking assignments are executed in the order specified in the > sequential block, i.e. a > blocking assignment waits for previous blocking assignment of the same > time to > complete before executing. > register =3D expression; > =E2=80=A2 Nonblocking assignment > Nonblocking assignments are executed concurrently within the sequential > blocks, i.e. a > nonblocking assignment executes without waiting for other nonblocking > assignments of > occurring at the same time to complete. > register <=3D expression; > -eoq- >=20 > > This is one of several reasons why software coders can't just "pick up"= an HDL language and run with it. They actually need to learn the language= and not assume it works like non-HDLs. Once they come to grips with a few= differences like this, it's not so special and anyone can code in HDLs.=20 >=20 > Yes. I'm actually a software guy who has fiddled around with hardware > ever since I left college. > A few weeks ago, I leafed through a book in the public library where it > said "The main difference between HDL and software programming is that > in HDL everything works in parallel". > As I'm working in a GUI (usually I'm a command-line-junky), I was only > concerned about this code block where I wanted to encapsulate this decodi= ng. Have you ever worked with Forth? Being a hardware guy I find the interacti= veness of Forth to be ideal for working with hardware. I can write code an= d then thoroughly test it from the command line, essentially without a comp= ile stage. More accurately, while other languages require a compiler to pr= oduce an executable image a resident Forth compiler on the target allows th= e code to be compiled during the source download with the compile being inv= isible. Or you type in your definitions to be tested interactively. =20 It's more than I can explain in a couple of paragraphs, but it's very nice = for interacting with hardware.=20 --=20 Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209Article: 161647
Hi, I have a data record designed as follows: type DATA_RECORD_t record I1: unsigned(7 downto 0); I2: unsigned(15 downto 0); end record; I want to get its bit number and don't want to manually calculate the bit number. How can I do it? Thank you. WengArticle: 161648
It is not clear what you really want to do but if you assign the bits in th= e record appropriately you can access bits and ranges using attributes of t= he record such as I1'high, I1'low, I2'range. For example,=20 type DATA_RECORD_t record=C2=A0 =C2=A0 I1: unsigned(7 downto 0);=C2=A0 =C2=A0 I2: unsigned(23 downto 8);=C2=A0 end record; Kevin JenningsArticle: 161649
On Thursday, February 13, 2020 at 4:53:45 PM UTC-8, KJ wrote: > It is not clear what you really want to do but if you assign the bits in = the record appropriately you can access bits and ranges using attributes of= the record such as I1'high, I1'low, I2'range. For example,=20 >=20 > type DATA_RECORD_t record=C2=A0 > =C2=A0 I1: unsigned(7 downto 0);=C2=A0 > =C2=A0 I2: unsigned(23 downto 8);=C2=A0 > end record; >=20 > Kevin Jennings Hi KJ, Thank you for your answer. I have a FIFO. Its data-in and data-out are data record. But a general FIFO= definition has data-in and data-out specified as follows:=09 =09 D_I : in unsigned(DATA_BITS-1 downto 0); -- data input So I hope to have a general method that does not need to calculate record's= bits. Your suggested method may work, but has no big difference from manually bit= counting. Weng
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