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 05/01/2020 19:24, Rick C wrote: > On Sunday, January 5, 2020 at 10:29:53 AM UTC-5, David Brown wrote: >> On 04/01/2020 20:59, Rick C wrote: >>> My projects typically are implemented in small devices and so >>> are often space constrained. So I am in the habit of optimizing >>> my code for implemented size. I've learned techniques that >>> minimize size and tend to use them everywhere rather than the >>> 20/80 rule of optimizing the 20% of the code where you get 80% of >>> the benefit, or 10/90 or whatever your favorite numbers are. >> >> This seems a little mixed up. The "20/80" (or whatever) rule is >> for /speed/ optimisation of software code. The principle is that >> if your program spends most of its time in 10% or 20% of the code, >> then that is the only part you need to optimise for speed. The >> rest of the code can be optimised for size. Optimising only 10% or >> 20% of your code for size is pointless. > > Lol! I guess you don't really understand HDL. My experience with HDL is small and outdated, but not non-existent. In software, at least in a language like C, you can very roughly approximate that the size of your C files corresponds to the size of the code. So if you pick 20% of your code and reduce its size by half, you have only reduced your overall code size by 10%. If you want to reduce the size of the total code by a meaningful amount, you have to look at most of the code. Is HDL design so different in your experience? Do you typically find that a mere 10% or 20% of the design accounts for the solid majority of the space? If you were talking about optimising for speed, then I would understand better - I can easily imagine that the maximum frequency for a design is limited by a few bottleneck points in the code, just as it often is in sequential software. > > >>> I remember interviewing at a Japanese based company once where >>> they worked differently. They were designing large projects and >>> felt it was counter productive to worry with optimizations of any >>> sort. They wanted fast turn around on their projects and so just >>> paid more for larger and faster parts I suppose. In fact in the >>> interview I was asked my opinion and gave it. A lead engineer >>> responded with a mini-lecture about how that was not productive >>> in their work. I responded with my take which was that once a >>> few techniques were learned about optimal coding techniques it >>> was not time consuming to make significant gains in logic size >>> and that these same techniques provided a consistent coding style >>> which allowed faster debug times. Turns out a reply was not >>> expected and in fact, went against a cultural difference >>> resulting in no offer from this company. >>> >>> I'm wondering where others' opinions and practice fall in this >>> area. I assume consistent coding practices are always encouraged. >>> How often do these practices include techniques to minimize size >>> or increase speed? What techniques are used to improve >>> debugging? >>> >> >> I can only really tell you about optimisation for software >> designs, rather than for programmable logic, > > Yes, that much we understand. > > >> but some things could be equally applicable. >> >> First, you have to distinguish between different types of >> "optimisation". The world simply means that you have a strong >> focus on one aspect of the development, nothing more. You can >> optimise for code speed, development speed, power requirements, >> safety, flexibility, or any one of dozens of different aspects. >> Some of these are run-time (like code speed), some are development >> time (like ease of debugging). You rarely really want to optimise, >> you just want to prioritise how you balance the different aspects >> of the development. > > There is your first mistake. Optimizing code can involve tradeoffs > between, size, speed, power consumption, etc., but can also involve > finding ways to improve multiple aspects without tradeoffs. You seem to want to argue, rather than discuss. I agree that working to improve one aspect (whether you call it "optimising" or not) can often improve other parts too. It is less common that there are /no/ tradeoffs, but certainly common that it is worth the cost. > > If you are going to talk about a tradeoff between code development > time (thinking) and other parametrics, then you are simply describing > the process of optimization. Duh! > > >> There are also many ways of considering optimisation for any one >> aspect. Typically, there are some things that involve lots of work, >> some things that involve knowledge and experience, and some things >> that can be automated. >> >> If we take the simple case of "code speed" optimisations, there >> are perhaps three main possibilities. >> >> 1. You can make a point of writing code that runs quickly. This is >> a matter of ability, knowledge and experience for the programmer. >> The programmer knows when to use data of different types, based on >> what will work well on the target device. He/she knows what >> algorithms make sense. He/she knows when to use multi-tasking and >> when to use a single threaded system - and so on. There is rarely >> any disadvantage in doing this sort of thing, unless it becomes >> /too/ smart - then it can lead to maintainability issues if the >> original developer is not available. > > Not at all rare that speed optimizations can create issues in other > areas. So that's your second mistake. Again, what's with this "mistake" nonsense? Or are you really saying that, unlike in sequential software development, when you do hardware development you find that making one part of your system fast breaks other parts? That sounds counter-intuitive to me, and does not match my limited HDL experience, but you have far more HDL experience than I. > > >> 2. You can enable compiler optimisations. This is usually a cheap >> step - it's just a compiler flag. Aggressive optimisations can >> make code harder to debug, but enabling basic optimisations >> typically makes it easier. It also improves static analysis and >> warnings, which is always a good thing. But there can be problems >> if the developers are not sufficiently trained or experienced, and >> tend to write "it worked when I tried it" code rather than knowing >> that their code is correct. >> >> 3. You can do a lot of work measuring performance and >> investigating different ways of handling the task at hand. This >> can lead to the biggest gains in speed - but also takes the most >> time and effort for developers. > > Which is the basis of the 20/80 rule. Don't spend time optimizing > code that isn't going to give a good return. > Yes, I know. > >> I expect the optimisations you are thinking of for programmable >> logic follow a similar pattern. >> >> And I think a fair amount of apparent disagreements about >> "optimisation" comes mainly from a misunderstanding about types of >> optimisation, and which type is under discussion. > > I think you didn't really read my original post where I mentioned > using optimization techniques consistently in my coding as a matter > of habit. Yes, I read it. That sounded very like the "type 1" optimisations I mentioned above. But the description of the Japanese company sounded like "type 2" and "type 3" optimisations. And it sounded like neither you nor that company understood the differences. (Note that I write here "it sounded like".) > Rather than brute force an algorithm into code in the most > direct way, I try to visualize the hardware that will implement the > task and then use HDL to describe that hardware. The alternative is > to code the algorithm directly and let the tools try to sort it out > in an efficient manner which often fails because they are constrained > to implement exactly what you have coded. > I would expect that methodology to work well sometimes, but not always. Again, let me compare this to the sequential software world - and you can tell me if this does not apply in HDL. When you are dealing with more limited compilers, it can often give the most efficient final results if you try to imagine the generated assembly, and try to arrange source code that would give that assembly. So people would use pointer arithmetic instead of arrays, write "x << 2" instead of "x * 4", and so on. But with better tools, writing the code cleanly and simply gives more efficient end results, because the compiler can handle the clear code better, and you have the benefits of source code that is easier to understand, easier to get right, harder to get wrong, and easier to maintain. Is it so different in the HDL world? Are the tools still so primitive? > Once I couldn't figure out why I was getting two adder chains when I > expected one chain with a carry output. Seems I had made some tiny > distinction between the two pieces of code so the adders were not > identical. So now my habit is to code the actual adder in a separate > line of code outside the process that is using it assuring it is the > same adder for both uses of the results. > Factoring out common code is regularly a good idea. > This is why it's still the 20/80 rule since there are large sections > of code that don't have much to gain from optimization. But a > halving of the size is significant for the sections of code that can > benefit. > But if you half the size of that 20%, your total is now 90% of the original. That is not typically a significant gain.Article: 161601
On Sunday, January 5, 2020 at 5:11:45 PM UTC-5, David Brown wrote: > On 05/01/2020 19:24, Rick C wrote: > > On Sunday, January 5, 2020 at 10:29:53 AM UTC-5, David Brown wrote: > >> On 04/01/2020 20:59, Rick C wrote: > >>> My projects typically are implemented in small devices and so > >>> are often space constrained. So I am in the habit of optimizing > >>> my code for implemented size. I've learned techniques that > >>> minimize size and tend to use them everywhere rather than the > >>> 20/80 rule of optimizing the 20% of the code where you get 80% of > >>> the benefit, or 10/90 or whatever your favorite numbers are. > >>=20 > >> This seems a little mixed up. The "20/80" (or whatever) rule is > >> for /speed/ optimisation of software code. The principle is that > >> if your program spends most of its time in 10% or 20% of the code, > >> then that is the only part you need to optimise for speed. The > >> rest of the code can be optimised for size. Optimising only 10% or > >> 20% of your code for size is pointless. > >=20 > > Lol! I guess you don't really understand HDL. >=20 > My experience with HDL is small and outdated, but not non-existent. >=20 > In software, at least in a language like C, you can very roughly=20 > approximate that the size of your C files corresponds to the size of the= =20 > code. So if you pick 20% of your code and reduce its size by half, you= =20 > have only reduced your overall code size by 10%. If you want to reduce= =20 > the size of the total code by a meaningful amount, you have to look at=20 > most of the code. >=20 > Is HDL design so different in your experience? Do you typically find=20 > that a mere 10% or 20% of the design accounts for the solid majority of= =20 > the space? Yes, in that 20% of the code is something that CAN be optimized for size. = Much of the code is straightforward and will produce what it produces with = no leeway. =20 > If you were talking about optimising for speed, then I would understand= =20 > better - I can easily imagine that the maximum frequency for a design is= =20 > limited by a few bottleneck points in the code, just as it often is in=20 > sequential software. Sometimes but it's not like sequentially executing code where the times all= add up and so much of the time is spent doing a lot of little things and a= few longer things. In HDL nearly everything is in parallel. So picture a= histogram with a spread of time delays. The longest delay is the clock sp= eed limiting path. Solve that and you bring the clock cycle in a small amo= unt to the next entry in the histogram. Lather, rinse, repeat. As you spe= ed up more of the long paths you will find you have to improve a larger num= ber of paths to get the same clock time improvement, resulting in the same = sort of 80/20 rule, but a bit different. It's more like you can address 20= % of the delay but then 80% remains intractable. So not really the same th= ing. It's a lot of work no matter what... unless the delays are because of= poor design which is always possible. =20 > >>> I remember interviewing at a Japanese based company once where > >>> they worked differently. They were designing large projects and > >>> felt it was counter productive to worry with optimizations of any > >>> sort. They wanted fast turn around on their projects and so just > >>> paid more for larger and faster parts I suppose. In fact in the > >>> interview I was asked my opinion and gave it. A lead engineer > >>> responded with a mini-lecture about how that was not productive > >>> in their work. I responded with my take which was that once a > >>> few techniques were learned about optimal coding techniques it > >>> was not time consuming to make significant gains in logic size > >>> and that these same techniques provided a consistent coding style > >>> which allowed faster debug times. Turns out a reply was not > >>> expected and in fact, went against a cultural difference > >>> resulting in no offer from this company. > >>>=20 > >>> I'm wondering where others' opinions and practice fall in this > >>> area. I assume consistent coding practices are always encouraged. > >>> How often do these practices include techniques to minimize size > >>> or increase speed? What techniques are used to improve > >>> debugging? > >>>=20 > >>=20 > >> I can only really tell you about optimisation for software > >> designs, rather than for programmable logic, > >=20 > > Yes, that much we understand. > >=20 > >=20 > >> but some things could be equally applicable. > >>=20 > >> First, you have to distinguish between different types of=20 > >> "optimisation". The world simply means that you have a strong > >> focus on one aspect of the development, nothing more. You can > >> optimise for code speed, development speed, power requirements, > >> safety, flexibility, or any one of dozens of different aspects. > >> Some of these are run-time (like code speed), some are development > >> time (like ease of debugging). You rarely really want to optimise, > >> you just want to prioritise how you balance the different aspects > >> of the development. > >=20 > > There is your first mistake. Optimizing code can involve tradeoffs > > between, size, speed, power consumption, etc., but can also involve > > finding ways to improve multiple aspects without tradeoffs. >=20 > You seem to want to argue, rather than discuss. I agree that working to= =20 > improve one aspect (whether you call it "optimising" or not) can often=20 > improve other parts too. It is less common that there are /no/=20 > tradeoffs, but certainly common that it is worth the cost. My original post wasn't really about optimizing after code was written. It= was about coding styles that achieve a level of optimization across the va= rious parameters before reviewing the results. So maybe that is why you fe= el like I am arguing with you. We aren't really discussing the same thing.= You acknowledge you have little experience in HDL yet seem to be forcing = a match to your experience in sequential coding. Try going with the flow h= ere and learn rather than trying to teach something you don't know.=20 > > If you are going to talk about a tradeoff between code development > > time (thinking) and other parametrics, then you are simply describing > > the process of optimization. Duh! > >=20 > >=20 > >> There are also many ways of considering optimisation for any one > >> aspect. Typically, there are some things that involve lots of work, > >> some things that involve knowledge and experience, and some things > >> that can be automated. > >>=20 > >> If we take the simple case of "code speed" optimisations, there > >> are perhaps three main possibilities. > >>=20 > >> 1. You can make a point of writing code that runs quickly. This is > >> a matter of ability, knowledge and experience for the programmer. > >> The programmer knows when to use data of different types, based on > >> what will work well on the target device. He/she knows what > >> algorithms make sense. He/she knows when to use multi-tasking and > >> when to use a single threaded system - and so on. There is rarely > >> any disadvantage in doing this sort of thing, unless it becomes > >> /too/ smart - then it can lead to maintainability issues if the > >> original developer is not available. > >=20 > > Not at all rare that speed optimizations can create issues in other > > areas. So that's your second mistake. >=20 > Again, what's with this "mistake" nonsense? Or are you really saying=20 > that, unlike in sequential software development, when you do hardware=20 > development you find that making one part of your system fast breaks=20 > other parts? That sounds counter-intuitive to me, and does not match my= =20 > limited HDL experience, but you have far more HDL experience than I. Perhaps I didn't understand your point. Rereading it I can't say I really = get your point other than the fact that speed optimizations can be complica= ted and hard to maintain. That is also true in HDL. Code that is worked a= nd reworked to find optimizations which can be nebulous and fragile. Logic= is always "optimized" by the compiler. Logic is not always simple and str= aightforward in a single assignment. In a complex CASE statement with cond= itionals a simple assignment can produce more complex logic than the writer= can appreciate. A small change can improve one thing and make another com= plex and slow. I use complex conditionals like CASE and nested IFs, but if= I want fast logic I separate that out and make it part of the 20% I'm spec= ifically optimizing (which is not the same as my original topic here).=20 I recall a CPU design I did where I targeted certain enables as fast decode= s and put them in a separate module.=20 =20 > >> 2. You can enable compiler optimisations. This is usually a cheap > >> step - it's just a compiler flag. Aggressive optimisations can > >> make code harder to debug, but enabling basic optimisations > >> typically makes it easier. It also improves static analysis and > >> warnings, which is always a good thing. But there can be problems > >> if the developers are not sufficiently trained or experienced, and > >> tend to write "it worked when I tried it" code rather than knowing > >> that their code is correct. > >>=20 > >> 3. You can do a lot of work measuring performance and > >> investigating different ways of handling the task at hand. This > >> can lead to the biggest gains in speed - but also takes the most > >> time and effort for developers. > >=20 > > Which is the basis of the 20/80 rule. Don't spend time optimizing > > code that isn't going to give a good return. > >=20 >=20 > Yes, I know. >=20 > >=20 > >> I expect the optimisations you are thinking of for programmable > >> logic follow a similar pattern. > >>=20 > >> And I think a fair amount of apparent disagreements about > >> "optimisation" comes mainly from a misunderstanding about types of > >> optimisation, and which type is under discussion. > >=20 > > I think you didn't really read my original post where I mentioned > > using optimization techniques consistently in my coding as a matter > > of habit.=20 >=20 > Yes, I read it. That sounded very like the "type 1" optimisations I=20 > mentioned above. But the description of the Japanese company sounded=20 > like "type 2" and "type 3" optimisations. =20 The Japanese company didn't do optimizations at all. That was the part tha= t surprised me. I tried to discuss it with them but the guy had what we wo= uld call an attitude about it. Clearly there was an issue with culture whe= re either I did not phrase my statements properly or I was simply not suppo= sed to question the guy at all.=20 I don't think there are type 2 optimizations so much, but then I haven't do= ne much with the tools in years. Maybe they have added levels of optimizat= ions, but I don't think the same things apply to HDL as sequential coding. = It's more a matter of payment if anything. You pay for specific features = in the tools which allow better results. I don't know for sure, I've alway= s used the free tools. I also mostly work on smaller tasks where I can use= the exploratory tools to see what my results are and see if they are match= ing my intent. That is the part the Japanese company didn't want to do.=20 > And it sounded like neither=20 > you nor that company understood the differences. (Note that I write=20 > here "it sounded like".) >=20 > > Rather than brute force an algorithm into code in the most > > direct way, I try to visualize the hardware that will implement the > > task and then use HDL to describe that hardware. The alternative is > > to code the algorithm directly and let the tools try to sort it out > > in an efficient manner which often fails because they are constrained > > to implement exactly what you have coded. > >=20 >=20 > I would expect that methodology to work well sometimes, but not always. >=20 > Again, let me compare this to the sequential software world - and you=20 > can tell me if this does not apply in HDL. When you are dealing with=20 > more limited compilers, it can often give the most efficient final=20 > results if you try to imagine the generated assembly, and try to arrange= =20 > source code that would give that assembly. So people would use pointer= =20 > arithmetic instead of arrays, write "x << 2" instead of "x * 4", and so= =20 > on. But with better tools, writing the code cleanly and simply gives=20 > more efficient end results, because the compiler can handle the clear=20 > code better, and you have the benefits of source code that is easier to= =20 > understand, easier to get right, harder to get wrong, and easier to=20 > maintain. >=20 > Is it so different in the HDL world? Are the tools still so primitive? I don't know because I really don't get what you are referring to. how is = x << 2 different from x * 4? I guess there might be an issue if X is a sig= ned number, so treat it as unsigned and they are the same. I had exactly t= hat sort of issue reading some code I wrote years ago for mulaw conversion.= The starting data was 16 bit signed of which only 14 bits are used includ= ing the sign bit. I wrote the code to be optimized and tossed out bits as = soon as they were no longer useful. Ultimately the algorithm uses 11 bits = to form the exponent and mantissa and of course the original sign bit. So = the number was converted to absolute value before doing the rest of the alg= orithm involving aligning the most significant '1' like a floating point nu= mber. Some of this involved shifting or multiplying depending on how you c= oded it. No difference to the tools that I am aware of.=20 On reviewing the code I got myself wrapped around the axle trying to figure= out if I had the head room to do the bias addition before the clipping and= had to write an app to calculate the mulaw data so I could more thoroughly= test this module over some data values that would show the flaw if it were= there. By the time I had the program written the confusion was gone and I= realized I had done it correctly the first time. Whew! I've got nearly 1= 0,000 of these in the field and they would have to be brought back for repr= ogramming the updates! =20 The point is the optimizations I did made it harder to "maintain" the code.= I don't see any way the compiler would have mattered. =20 > > Once I couldn't figure out why I was getting two adder chains when I > > expected one chain with a carry output. Seems I had made some tiny > > distinction between the two pieces of code so the adders were not > > identical. So now my habit is to code the actual adder in a separate > > line of code outside the process that is using it assuring it is the > > same adder for both uses of the results. > >=20 >=20 > Factoring out common code is regularly a good idea. No, no, not common code, two adders instantiated for the same functionality= . If you are decrementing a count and want to detect it being at zero you = can use the carry out. No need for two counters as long as you code it rig= ht.=20 X <=3D X - 1;=20 and elsewhere If X =3D 0=20 I also don't want an N bit compare to all zero bits in the word.=20 > > This is why it's still the 20/80 rule since there are large sections > > of code that don't have much to gain from optimization. But a > > halving of the size is significant for the sections of code that can > > benefit. > >=20 >=20 > But if you half the size of that 20%, your total is now 90% of the=20 > original. That is not typically a significant gain. Lol! If you have 1 MB of code space and your code is 1.001 MB, 90% is very= significant. Maybe that's still too close for comfort in a CPU, but if yo= u can get it into the FPGA at 90% utilization 90% is golden. =20 Besides the numbers don't necessarily add up the way you indicate. I think= I've said before, some code produces more logic than other. A perfect exa= mple is the multiplier I had to use in the front end of a DSP path vs. the = multiplier I used in an audio path. The former was optimized to use just e= nough bits to get the job done since it needed to run at close to the clock= rate so it used a fair number of LUTs (the target part had no multipliers)= . The latter was in an audio path that could process it in multiple clocks= and used a lot less logic, but I had to optimize this one differently. =20 The optimizations that would be more like what is done in software might by= the algorithmic optimizations where different ways of designing the algori= thm are considered. I don't know. I don't typically need to optimize any = of the software I write. It all runs pretty well on today's CPUs, even the= tiny ones in my FPGAs. Oh, and I avoid languages like C. I use Forth or = assembly which is nearly the same thing on my CPUs.=20 --=20 Rick C. -+ Get 1,000 miles of free Supercharging -+ Tesla referral code - https://ts.la/richard11209Article: 161602
David Brown <david.brown@hesbynett.no> wrote:
> Again, let me compare this to the sequential software world - and you
> can tell me if this does not apply in HDL. When you are dealing with
> more limited compilers, it can often give the most efficient final
> results if you try to imagine the generated assembly, and try to arrange
> source code that would give that assembly. So people would use pointer
> arithmetic instead of arrays, write "x << 2" instead of "x * 4", and so
> on. But with better tools, writing the code cleanly and simply gives
> more efficient end results, because the compiler can handle the clear
> code better, and you have the benefits of source code that is easier to
> understand, easier to get right, harder to get wrong, and easier to
> maintain.
>
> Is it so different in the HDL world? Are the tools still so primitive?
I think the issue in the HDL world is the 'instruction set' is a lot more
complex. Let's take a software analogy...
Essentially, a compiler is trying to pattern match the high level code you
wrote with a toolbox of lower level pieces ('instructions' in the software
case). The 1980s RISC movement was all about making those instructions
simpler and faster, so the compiler could use half a dozen to represent an
operation instead of 1-2 CISC instructions. Over the years compilers have
got better at using those RISC instructions and optimising away redundancy
between HLL statements.
In the FPGA and ASIC world, you have extremely CISC-y 'instructions'. So
instead of shifts and adds, you have complexity equivalent to VAX's
polynomial multiply instruction. The compiler now has to read your C code
and decide what to fit to a polynomial multiply. Maybe it can spot:
p = a*x*x + b*x + c;
(which would become POLY p,x,c,b,a for my fictional polynomial expansion
instruction)
but change that to:
p = a*x*y + b*x + c;
and suddenly it doesn't match any more (it's no longer a polynomial in terms
of x).
So you do need to code thinking about how it might implement your system,
because you do have to convince the compiler to fit your code to the
primitives you have. If you code slightly differently such the compiler
doesn't miss your pattern, you end up with a bit pile of registers rather
than a BRAM, an expanded multiply rather than a DSP block, or whatever it
might be.
The job of an FPGA compiler is a lot harder than a software compiler, and so
you need to feed it more carefully.
Theo
(my mention of the VAX instruction set is but a caricature used for
rhetorical purposes - I've never actually programmed one)
Article: 161603
On 06/01/2020 00:42, Theo wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> Again, let me compare this to the sequential software world - and you
>> can tell me if this does not apply in HDL. When you are dealing with
>> more limited compilers, it can often give the most efficient final
>> results if you try to imagine the generated assembly, and try to arrange
>> source code that would give that assembly. So people would use pointer
>> arithmetic instead of arrays, write "x << 2" instead of "x * 4", and so
>> on. But with better tools, writing the code cleanly and simply gives
>> more efficient end results, because the compiler can handle the clear
>> code better, and you have the benefits of source code that is easier to
>> understand, easier to get right, harder to get wrong, and easier to
>> maintain.
>>
>> Is it so different in the HDL world? Are the tools still so primitive?
>
> I think the issue in the HDL world is the 'instruction set' is a lot more
> complex. Let's take a software analogy...
>
> Essentially, a compiler is trying to pattern match the high level code you
> wrote with a toolbox of lower level pieces ('instructions' in the software
> case). The 1980s RISC movement was all about making those instructions
> simpler and faster, so the compiler could use half a dozen to represent an
> operation instead of 1-2 CISC instructions. Over the years compilers have
> got better at using those RISC instructions and optimising away redundancy
> between HLL statements.
>
In assembly, one "high level" statement or expression is essentially
turned into one machine code instruction (though this is not always
true). For low-level languages with simpler compilers, such as earlier
or more limited C compilers, each section of bit of source code was
translated into a particular set of assembly instructions. But for most
software languages, and modern compilers for languages like C, it's a
different matter. The source code describes operations defined on an
abstract machine, and it is up to the compiler to generate assembly that
gives the requested results.
> In the FPGA and ASIC world, you have extremely CISC-y 'instructions'. So
> instead of shifts and adds, you have complexity equivalent to VAX's
> polynomial multiply instruction. The compiler now has to read your C code
> and decide what to fit to a polynomial multiply. Maybe it can spot:
>
> p = a*x*x + b*x + c;
>
> (which would become POLY p,x,c,b,a for my fictional polynomial expansion
> instruction)
>
> but change that to:
>
> p = a*x*y + b*x + c;
>
> and suddenly it doesn't match any more (it's no longer a polynomial in terms
> of x).
>
> So you do need to code thinking about how it might implement your system,
> because you do have to convince the compiler to fit your code to the
> primitives you have. If you code slightly differently such the compiler
> doesn't miss your pattern, you end up with a bit pile of registers rather
> than a BRAM, an expanded multiply rather than a DSP block, or whatever it
> might be.
For some kinds of software coding, you will be thinking in the same
lines. For example, you might code thinking "I'll make sure I use
single-precision floating point here, because my cpu has hardware for
that, and avoid double-precision because that uses slow software emulation".
So yes, I understand what you mean - and I know that is something that
can be very relevant in HDL coding.
And for both sequential software and HDL development, much of this is
down to the knowledge and experience of the programmer - and the
required portability of the code.
>
> The job of an FPGA compiler is a lot harder than a software compiler, and so
> you need to feed it more carefully.
>
Both need careful feeding to be sure of getting correct results (that's
the main point), and to prefer efficient results (a secondary aim, but
still very important).
> Theo
>
> (my mention of the VAX instruction set is but a caricature used for
> rhetorical purposes - I've never actually programmed one)
>
Article: 161604
On 06/01/2020 00:13, Rick C wrote:
> On Sunday, January 5, 2020 at 5:11:45 PM UTC-5, David Brown wrote:
>> On 05/01/2020 19:24, Rick C wrote:
>>> On Sunday, January 5, 2020 at 10:29:53 AM UTC-5, David Brown
>>> wrote:
>>>> On 04/01/2020 20:59, Rick C wrote:
>>>>> My projects typically are implemented in small devices and
>>>>> so are often space constrained. So I am in the habit of
>>>>> optimizing my code for implemented size. I've learned
>>>>> techniques that minimize size and tend to use them everywhere
>>>>> rather than the 20/80 rule of optimizing the 20% of the code
>>>>> where you get 80% of the benefit, or 10/90 or whatever your
>>>>> favorite numbers are.
>>>>
>>>> This seems a little mixed up. The "20/80" (or whatever) rule
>>>> is for /speed/ optimisation of software code. The principle is
>>>> that if your program spends most of its time in 10% or 20% of
>>>> the code, then that is the only part you need to optimise for
>>>> speed. The rest of the code can be optimised for size.
>>>> Optimising only 10% or 20% of your code for size is pointless.
>>>
>>> Lol! I guess you don't really understand HDL.
>>
>> My experience with HDL is small and outdated, but not
>> non-existent.
>>
>> In software, at least in a language like C, you can very roughly
>> approximate that the size of your C files corresponds to the size
>> of the code. So if you pick 20% of your code and reduce its size
>> by half, you have only reduced your overall code size by 10%. If
>> you want to reduce the size of the total code by a meaningful
>> amount, you have to look at most of the code.
>>
>> Is HDL design so different in your experience? Do you typically
>> find that a mere 10% or 20% of the design accounts for the solid
>> majority of the space?
>
> Yes, in that 20% of the code is something that CAN be optimized for
> size. Much of the code is straightforward and will produce what it
> produces with no leeway.
That is not answering my question. I can well understand that only a
small proportion of the code offers much scope for size optimisation -
the same is true of sequential software. And in both sequential
software and HDL design, a substantial part of the bulk is usually taken
by libraries or pre-generated blocks of some kind, which offer little
scope for developer optimisation - just basic compiler flags for
"optimise for speed" or "optimise for size".
What I asked, was if this 20% of the code that you /can/ optimise for
space accounts for a solid majority of the final placed and routed
binary? If it does not - as I suspect is the case in most designs -
then you can never make more than a dent in the total space no matter
how you improve that 20%.
I am not saying that you shouldn't write that 20% as best you can, nor
do I disagree that doing so will likely give many other benefits. What
I am saying is that optimising it primarily for size is not often a
meaningful aim in itself.
>
>
>> If you were talking about optimising for speed, then I would
>> understand better - I can easily imagine that the maximum frequency
>> for a design is limited by a few bottleneck points in the code,
>> just as it often is in sequential software.
>
> Sometimes but it's not like sequentially executing code where the
> times all add up and so much of the time is spent doing a lot of
> little things and a few longer things. In HDL nearly everything is
> in parallel.
Yes, I appreciate that.
> So picture a histogram with a spread of time delays.
> The longest delay is the clock speed limiting path. Solve that and
> you bring the clock cycle in a small amount to the next entry in the
> histogram. Lather, rinse, repeat. As you speed up more of the long
> paths you will find you have to improve a larger number of paths to
> get the same clock time improvement, resulting in the same sort of
> 80/20 rule, but a bit different. It's more like you can address 20%
> of the delay but then 80% remains intractable. So not really the
> same thing. It's a lot of work no matter what... unless the delays
> are because of poor design which is always possible.
>
It is not hugely different for sequential software, and follows a
similar pattern - it is often just a small part of the code that limits
the speed of the system. There are differences in the details, of
course - with HDL it doesn't matter how much you improve the speed of a
part that is not the limiting path. (Software can often consist of
multiple threads in parallel, which can make it a little more like HDL
here - though obviously the scale of the parallelism is very different.)
>
>>>>> I remember interviewing at a Japanese based company once
>>>>> where they worked differently. They were designing large
>>>>> projects and felt it was counter productive to worry with
>>>>> optimizations of any sort. They wanted fast turn around on
>>>>> their projects and so just paid more for larger and faster
>>>>> parts I suppose. In fact in the interview I was asked my
>>>>> opinion and gave it. A lead engineer responded with a
>>>>> mini-lecture about how that was not productive in their work.
>>>>> I responded with my take which was that once a few techniques
>>>>> were learned about optimal coding techniques it was not time
>>>>> consuming to make significant gains in logic size and that
>>>>> these same techniques provided a consistent coding style
>>>>> which allowed faster debug times. Turns out a reply was not
>>>>> expected and in fact, went against a cultural difference
>>>>> resulting in no offer from this company.
>>>>>
>>>>> I'm wondering where others' opinions and practice fall in
>>>>> this area. I assume consistent coding practices are always
>>>>> encouraged. How often do these practices include techniques
>>>>> to minimize size or increase speed? What techniques are used
>>>>> to improve debugging?
>>>>>
>>>>
>>>> I can only really tell you about optimisation for software
>>>> designs, rather than for programmable logic,
>>>
>>> Yes, that much we understand.
>>>
>>>
>>>> but some things could be equally applicable.
>>>>
>>>> First, you have to distinguish between different types of
>>>> "optimisation". The world simply means that you have a strong
>>>> focus on one aspect of the development, nothing more. You can
>>>> optimise for code speed, development speed, power
>>>> requirements, safety, flexibility, or any one of dozens of
>>>> different aspects. Some of these are run-time (like code
>>>> speed), some are development time (like ease of debugging). You
>>>> rarely really want to optimise, you just want to prioritise how
>>>> you balance the different aspects of the development.
>>>
>>> There is your first mistake. Optimizing code can involve
>>> tradeoffs between, size, speed, power consumption, etc., but can
>>> also involve finding ways to improve multiple aspects without
>>> tradeoffs.
>>
>> You seem to want to argue, rather than discuss. I agree that
>> working to improve one aspect (whether you call it "optimising" or
>> not) can often improve other parts too. It is less common that
>> there are /no/ tradeoffs, but certainly common that it is worth the
>> cost.
>
> My original post wasn't really about optimizing after code was
> written. It was about coding styles that achieve a level of
> optimization across the various parameters before reviewing the
> results. So maybe that is why you feel like I am arguing with you.
> We aren't really discussing the same thing.
That is, I think, very much my point. "Optimisation" can mean so many
things, and it is vital to understand the differences, and make it clear
what you mean by it.
> You acknowledge you have
> little experience in HDL yet seem to be forcing a match to your
> experience in sequential coding. Try going with the flow here and
> learn rather than trying to teach something you don't know.
>
I see this as a discussion, not "teaching" - I am sharing experiences
and thoughts, and trying to provoke other thoughts and suggesting other
viewpoints. It is not about being right or wrong, or teaching and
learning, it is about swapping thoughts and experiences. It is about
looking at analogies from related fields - there is a lot to be learned
by looking across sequential software development, HDL development, and
electronics hardware development.
>
>>> If you are going to talk about a tradeoff between code
>>> development time (thinking) and other parametrics, then you are
>>> simply describing the process of optimization. Duh!
>>>
>>>
>>>> There are also many ways of considering optimisation for any
>>>> one aspect. Typically, there are some things that involve lots
>>>> of work, some things that involve knowledge and experience, and
>>>> some things that can be automated.
>>>>
>>>> If we take the simple case of "code speed" optimisations,
>>>> there are perhaps three main possibilities.
>>>>
>>>> 1. You can make a point of writing code that runs quickly.
>>>> This is a matter of ability, knowledge and experience for the
>>>> programmer. The programmer knows when to use data of different
>>>> types, based on what will work well on the target device.
>>>> He/she knows what algorithms make sense. He/she knows when to
>>>> use multi-tasking and when to use a single threaded system -
>>>> and so on. There is rarely any disadvantage in doing this sort
>>>> of thing, unless it becomes /too/ smart - then it can lead to
>>>> maintainability issues if the original developer is not
>>>> available.
>>>
>>> Not at all rare that speed optimizations can create issues in
>>> other areas. So that's your second mistake.
>>
>> Again, what's with this "mistake" nonsense? Or are you really
>> saying that, unlike in sequential software development, when you do
>> hardware development you find that making one part of your system
>> fast breaks other parts? That sounds counter-intuitive to me, and
>> does not match my limited HDL experience, but you have far more HDL
>> experience than I.
>
> Perhaps I didn't understand your point. Rereading it I can't say I
> really get your point other than the fact that speed optimizations
> can be complicated and hard to maintain. That is also true in HDL.
I have been trying to describe different meanings of "optimisation" - I
don't think it makes sense to talk about how much optimisation you
should do until it established which kind of optimisation you are
talking about. (I have a much better idea of this than from your
original post - so in that way, the discussion has been helpful.)
> Code that is worked and reworked to find optimizations which can be
> nebulous and fragile. Logic is always "optimized" by the compiler.
> Logic is not always simple and straightforward in a single
> assignment. In a complex CASE statement with conditionals a simple
> assignment can produce more complex logic than the writer can
> appreciate. A small change can improve one thing and make another
> complex and slow.
Yes, I understand that. This is perhaps one way in which HDL (at least,
with Verilog or VHDL) can be harder than sequential software - it is
really easy to get large effects from small changes to the code in
things like a complex CASE statement. In particular, you can very
easily create a latch unintentionally.
The solution to this kind of thing is the same in sequential software
and HDL - modularisation, factoring out common code, and using
higher-level features or higher-level languages.
(Higher level HDLs, like MyHDL, Spinal, Confluence, etc. invariably make
a point of making it very clear when you are generating synchronous or
combinatorial logic, as far as I have seen.)
Going the other way, one thing that is easy to do in sequential software
(in most languages), but hard to do in HDL, is have multiple places
where you assign to the same variable. This is often a source of errors
in sequential code - and thinking of your variables like hardware
signals or registers that are fed from one place and read from many, can
give you much better code.
> I use complex conditionals like CASE and nested
> IFs, but if I want fast logic I separate that out and make it part of
> the 20% I'm specifically optimizing (which is not the same as my
> original topic here).
>
> I recall a CPU design I did where I targeted certain enables as fast
> decodes and put them in a separate module.
>
>
>>>> 2. You can enable compiler optimisations. This is usually a
>>>> cheap step - it's just a compiler flag. Aggressive
>>>> optimisations can make code harder to debug, but enabling basic
>>>> optimisations typically makes it easier. It also improves
>>>> static analysis and warnings, which is always a good thing.
>>>> But there can be problems if the developers are not
>>>> sufficiently trained or experienced, and tend to write "it
>>>> worked when I tried it" code rather than knowing that their
>>>> code is correct.
>>>>
>>>> 3. You can do a lot of work measuring performance and
>>>> investigating different ways of handling the task at hand.
>>>> This can lead to the biggest gains in speed - but also takes
>>>> the most time and effort for developers.
>>>
>>> Which is the basis of the 20/80 rule. Don't spend time
>>> optimizing code that isn't going to give a good return.
>>>
>>
>> Yes, I know.
>>
>>>
>>>> I expect the optimisations you are thinking of for
>>>> programmable logic follow a similar pattern.
>>>>
>>>> And I think a fair amount of apparent disagreements about
>>>> "optimisation" comes mainly from a misunderstanding about types
>>>> of optimisation, and which type is under discussion.
>>>
>>> I think you didn't really read my original post where I
>>> mentioned using optimization techniques consistently in my coding
>>> as a matter of habit.
>>
>> Yes, I read it. That sounded very like the "type 1" optimisations
>> I mentioned above. But the description of the Japanese company
>> sounded like "type 2" and "type 3" optimisations.
>
> The Japanese company didn't do optimizations at all. That was the
> part that surprised me. I tried to discuss it with them but the guy
> had what we would call an attitude about it. Clearly there was an
> issue with culture where either I did not phrase my statements
> properly or I was simply not supposed to question the guy at all.
>
My guess would be a bit of both - you could easily have been meaning
different things when talking about optimisations. And there can
certainly be cultural differences - Japanese society is a lot more
strictly hierarchical that is usually found in small Western companies.
> I don't think there are type 2 optimizations so much, but then I
> haven't done much with the tools in years. Maybe they have added
> levels of optimizations, but I don't think the same things apply to
> HDL as sequential coding. It's more a matter of payment if anything.
> You pay for specific features in the tools which allow better
> results. I don't know for sure, I've always used the free tools.
Certainly it seems common practice for the paid-for versions to have
more features. I haven't kept up with FPGA tools for a long time, but I
know it was common to have things like parallel place and/or route in
the paid versions - leading to faster build times. Whether they also
had more or less optimisations, I don't know. But I do remember a
certain amount of flags and options for logic generation that could be
considered optimisations. However, it is perhaps not really equivalent
to optimisation flags in sequential programming tools.
(In the software world, you sometimes get tools where you have to pay,
or pay more, for an optimising compiler.)
> I
> also mostly work on smaller tasks where I can use the exploratory
> tools to see what my results are and see if they are matching my
> intent. That is the part the Japanese company didn't want to do.
>
>
>> And it sounded like neither you nor that company understood the
>> differences. (Note that I write here "it sounded like".)
>>
>>> Rather than brute force an algorithm into code in the most direct
>>> way, I try to visualize the hardware that will implement the task
>>> and then use HDL to describe that hardware. The alternative is
>>> to code the algorithm directly and let the tools try to sort it
>>> out in an efficient manner which often fails because they are
>>> constrained to implement exactly what you have coded.
>>>
>>
>> I would expect that methodology to work well sometimes, but not
>> always.
>>
>> Again, let me compare this to the sequential software world - and
>> you can tell me if this does not apply in HDL. When you are
>> dealing with more limited compilers, it can often give the most
>> efficient final results if you try to imagine the generated
>> assembly, and try to arrange source code that would give that
>> assembly. So people would use pointer arithmetic instead of
>> arrays, write "x << 2" instead of "x * 4", and so on. But with
>> better tools, writing the code cleanly and simply gives more
>> efficient end results, because the compiler can handle the clear
>> code better, and you have the benefits of source code that is
>> easier to understand, easier to get right, harder to get wrong, and
>> easier to maintain.
>>
>> Is it so different in the HDL world? Are the tools still so
>> primitive?
>
> I don't know because I really don't get what you are referring to.
> how is x << 2 different from x * 4? I guess there might be an issue
> if X is a signed number, so treat it as unsigned and they are the
> same.
In the software world, imagine a small, simple cpu core with no hardware
multiply. Directly translated, "x << 2" can probably be done with two
"rotate left" instructions. Directly translated, "x * 4" would call the
library multiplication function. There would be a huge difference in
the timing of the two implementations.
There was a time when manually writing "x << 2" instead of "x * 4" was a
good idea, at least for some compilers. However, for any half-decent
compiler, you will get the same results - and thus you should write the
code in the way that is the most obvious and clearest, /not/ in the way
you think matches the assembly you think should be generated.
In the HDL world, "x * 4" might be implemented using a DSP multiplier
block - and "x << 2" might be done just by routing of the signals. I
would hope that you are able to write "x * 4" in the HDL when that is
the more natural way to express your intent, and the tools will
implement it as though you had written "x << 2".
And in reference to signed and unsigned data - this means you can write
your code in clearer arithmetic, without having to be so concerned about
the details of the sign bits. (With two's complement integers, you can
do your multiplications with a disregard for signedness, but it can be
complicated for division. Let the compiler figure out how to handle the
sign, or which shift instructions to use, or when biased arithmetic
makes most sense, or when to turn division by a constant into
multiplication by a constant.)
Does that make it a little clearer?
> I had exactly that sort of issue reading some code I wrote
> years ago for mulaw conversion. The starting data was 16 bit signed
> of which only 14 bits are used including the sign bit. I wrote the
> code to be optimized and tossed out bits as soon as they were no
> longer useful. Ultimately the algorithm uses 11 bits to form the
> exponent and mantissa and of course the original sign bit. So the
> number was converted to absolute value before doing the rest of the
> algorithm involving aligning the most significant '1' like a floating
> point number. Some of this involved shifting or multiplying
> depending on how you coded it. No difference to the tools that I am
> aware of.
>
> On reviewing the code I got myself wrapped around the axle trying to
> figure out if I had the head room to do the bias addition before the
> clipping and had to write an app to calculate the mulaw data so I
> could more thoroughly test this module over some data values that
> would show the flaw if it were there. By the time I had the program
> written the confusion was gone and I realized I had done it correctly
> the first time. Whew! I've got nearly 10,000 of these in the field
> and they would have to be brought back for reprogramming the updates!
>
>
> The point is the optimizations I did made it harder to "maintain" the
> code. I don't see any way the compiler would have mattered.
>
Can't you write this sort of thing at a higher level, using normal
arithmetic, and let the tools figure out the details? What you are
describing sounds like the equivalent of assembly programming in
sequential software - and it is a long time since that has made sense
for all but the most niche cases. (I have a long history as an assembly
programmer - and I'm glad I don't have to do so any more.)
As an example in software, consider a "divide by three" function.
Division instructions - assuming the cpu has one - are generally very
slow. This is what a compiler generates for ARM code:
int div_by_three(int x) {
return x / 3;
}
div_by_three(int):
ldr r3, .L5
smull r2, r3, r3, r0
sub r0, r3, r0, asr #31
bx lr
.L5:
.word 1431655766
The compiler transforms the division into a multiplication, with shifts
and biases to get it exactly right, for all values, positive and
negative. I don't need to go through hours of work figuring out the
numbers to use here, and hours more in comprehensive testing of corner
cases.
But go back a number of years, or switch to poorer tools, and the
compiler would be generating division code - and thus there would be a
lot of scope for manually optimising the code (if the speed mattered, of
course).
Do HDL tools do this kind of arithmetic transformation automatically?
>
>>> Once I couldn't figure out why I was getting two adder chains
>>> when I expected one chain with a carry output. Seems I had made
>>> some tiny distinction between the two pieces of code so the
>>> adders were not identical. So now my habit is to code the actual
>>> adder in a separate line of code outside the process that is
>>> using it assuring it is the same adder for both uses of the
>>> results.
>>>
>>
>> Factoring out common code is regularly a good idea.
>
> No, no, not common code, two adders instantiated for the same
> functionality. If you are decrementing a count and want to detect it
> being at zero you can use the carry out. No need for two counters as
> long as you code it right.
>
> X <= X - 1; and elsewhere If X = 0
>
> I also don't want an N bit compare to all zero bits in the word.
>
Ah, okay.
>
>>> This is why it's still the 20/80 rule since there are large
>>> sections of code that don't have much to gain from optimization.
>>> But a halving of the size is significant for the sections of code
>>> that can benefit.
>>>
>>
>> But if you half the size of that 20%, your total is now 90% of the
>> original. That is not typically a significant gain.
>
> Lol! If you have 1 MB of code space and your code is 1.001 MB, 90%
> is very significant. Maybe that's still too close for comfort in a
> CPU, but if you can get it into the FPGA at 90% utilization 90% is
> golden.
Of course there are edge cases where a 10% improvement in code space
makes a world of difference. It's the same in software.
The difference is, a 50% improvement in the code density of the key 20%
leads to a 10% improvement in the end result for size. A 50%
improvement in the speed of the key 20% can give close to 50%
improvement in the end result for speed. A 50% improvement is usually
significant - a 10% improvement usually not.
>
> Besides the numbers don't necessarily add up the way you indicate.
Of course not - these are very rough, and will certainly not always be
remotely realistic.
> I
> think I've said before, some code produces more logic than other. A
> perfect example is the multiplier I had to use in the front end of a
> DSP path vs. the multiplier I used in an audio path. The former was
> optimized to use just enough bits to get the job done since it needed
> to run at close to the clock rate so it used a fair number of LUTs
> (the target part had no multipliers). The latter was in an audio
> path that could process it in multiple clocks and used a lot less
> logic, but I had to optimize this one differently.
>
> The optimizations that would be more like what is done in software
> might by the algorithmic optimizations where different ways of
> designing the algorithm are considered. I don't know. I don't
> typically need to optimize any of the software I write. It all runs
> pretty well on today's CPUs, even the tiny ones in my FPGAs. Oh, and
> I avoid languages like C. I use Forth or assembly which is nearly
> the same thing on my CPUs.
>
Article: 161605On Sunday, January 5, 2020 at 6:33:05 PM UTC, Rick C wrote: >=20 > Interesting effort. I'm surprised the result is so small. I'm also surp= rised the Cyclone V result is smaller than the Artix 7 result. Any idea wh= y the register count varies? Usually the register count is fixed by the co= de. Did the tools use register splitting for speed?=20 >=20 A state machine is a significant part of the design, so I expect that to be= the main reason for differences in register count, depending on how the im= plementation tools decide to encode the state machine. The number of LUTs a= nd registers also vary depending on tool optimisation settings. The registe= r and LUT counts on the s430 page are for default tool settings. > Does it take a lot of cycles to run code?=20 Yes it does, see the cycle count for a selection of instructions on the s43= 0 page. The design is not a pipelined processor design, which saves logic o= f course but hurts performance. When I designed it I very roughly aimed at = less than 50% resources in the ~1200 LUT/FF machxo3 devices for low power p= rocessing tasks with gcc. Part of the reason it's small is that it doesn't have the 16-bit ALU, but t= hen two clocks are required instead of one for an ALU operation. I seem to = recall reading somewhere that some of the earlier Z80s had 4-bit ALU's rath= er than 8 to save on space, so I think that's been done for a while now :). Interestingly on Github there is a NEO430 project that someone else has des= igned, and the end results there are not too dissimilar to what I've got, n= oting the optimisations I used.Article: 161606
On Monday, January 6, 2020 at 1:34:47 PM UTC-5, pau...@googlemail.com wrote= : > On Sunday, January 5, 2020 at 6:33:05 PM UTC, Rick C wrote: > >=20 > > Interesting effort. I'm surprised the result is so small. I'm also su= rprised the Cyclone V result is smaller than the Artix 7 result. Any idea = why the register count varies? Usually the register count is fixed by the = code. Did the tools use register splitting for speed?=20 > >=20 >=20 > A state machine is a significant part of the design, so I expect that to = be the main reason for differences in register count, depending on how the = implementation tools decide to encode the state machine. The number of LUTs= and registers also vary depending on tool optimisation settings. The regis= ter and LUT counts on the s430 page are for default tool settings. >=20 > > Does it take a lot of cycles to run code?=20 >=20 > Yes it does, see the cycle count for a selection of instructions on the s= 430 page. The design is not a pipelined processor design, which saves logic= of course but hurts performance. When I designed it I very roughly aimed a= t less than 50% resources in the ~1200 LUT/FF machxo3 devices for low power= processing tasks with gcc. >=20 > Part of the reason it's small is that it doesn't have the 16-bit ALU, but= then two clocks are required instead of one for an ALU operation. I seem t= o recall reading somewhere that some of the earlier Z80s had 4-bit ALU's ra= ther than 8 to save on space, so I think that's been done for a while now := ). >=20 > Interestingly on Github there is a NEO430 project that someone else has d= esigned, and the end results there are not too dissimilar to what I've got,= noting the optimisations I used. Thanks, it's always interesting to see not just the results, but the goals = and motivations for CPU projects. =20 I think you might be referring to the Z8 rather than the Z80? I guess ther= e were some clones but I don't think the original Z80 had a 4 bit, double p= umped ALU. Sounds more like something done in a Chinese 4 bit processor bu= ilt to run Z80 code. The Z8 on the other hand was all about low selling pr= ice, so they may well have minimized the ALU and other logic this way.=20 Anyone know if the 4 bit MCUs are still dominating the low end of the CPU m= arket or have the cost differences with the 8 bit devices faded away?=20 --=20 Rick C. +- Get 1,000 miles of free Supercharging +- Tesla referral code - https://ts.la/richard11209Article: 161607
I bet the Apple still have a huge leg up on PCs when it comes to displays. = Yeah, they both have the same hardware these days, but the way the softwar= e manages things is so much better on the Mac. I remember using a Mac many= years ago and everything from top to bottom had a consistent look and feel= . On the PC every program is in it's own world with unique fonts, sizes an= d windows. =20 I had this machine fairly tuned up and could get most things done without e= ye strain and yet still got to treat the display as if it could show more t= han one window at a time. Then I fired up an HDL tool and the fonts are al= l so small it was impossible to read them without surgeon's magnifiers. So= I finally gave in and went for the Windows screen adjustment. Seems I alr= eady had it set to 125%. So I thought 150% might do well... adjust, reboot= and the screen looked like I had dropped the resolution to 1024 instead of= 1920 pixels wide. Everything was so huge! Ok, so I backed that off to 13= 5% and it seems to be a bit better, the new app can be read with only a bit= of eye strain. But now I have to go into every app and tweak details to g= et it to look right again. =20 On the Mac, if I could read one app, I could read them all! Too bad so muc= h engineering software won't run on the Mac.=20 So how does Linux handle things like font sizes? I'm thinking it is really= the wild west or it forces the user to manually muck with all the settings= on every program. At least I can get a lot more engineering tools to run = under Linux than on the Mac. I really do need to try Linux sometime.=20 --=20 Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209Article: 161608
On 1/7/20 8:00 PM, Rick C wrote: > I bet the Apple still have a huge leg up on PCs when it comes to displays. Yeah, they both have the same hardware these days, but the way the software manages things is so much better on the Mac. I remember using a Mac many years ago and everything from top to bottom had a consistent look and feel. On the PC every program is in it's own world with unique fonts, sizes and windows. > > I had this machine fairly tuned up and could get most things done without eye strain and yet still got to treat the display as if it could show more than one window at a time. Then I fired up an HDL tool and the fonts are all so small it was impossible to read them without surgeon's magnifiers. So I finally gave in and went for the Windows screen adjustment. Seems I already had it set to 125%. So I thought 150% might do well... adjust, reboot and the screen looked like I had dropped the resolution to 1024 instead of 1920 pixels wide. Everything was so huge! Ok, so I backed that off to 135% and it seems to be a bit better, the new app can be read with only a bit of eye strain. But now I have to go into every app and tweak details to get it to look right again. > > On the Mac, if I could read one app, I could read them all! Too bad so much engineering software won't run on the Mac. > > So how does Linux handle things like font sizes? I'm thinking it is really the wild west or it forces the user to manually muck with all the settings on every program. At least I can get a lot more engineering tools to run under Linux than on the Mac. I really do need to try Linux sometime. > Generally pretty well. I've been daily driving on Linux machines for about a decade now and would never consider going back. That said, Modelsim on Linux does in fact have a font problem that requires manually mucking with hidden settings in an undocumented way, otherwise it's like you're trying to read source from orbit.Article: 161609
On Wednesday, January 8, 2020 at 12:29:20 PM UTC-5, Rob Gaddi wrote: > On 1/7/20 8:00 PM, Rick C wrote: > > I bet the Apple still have a huge leg up on PCs when it comes to displa= ys. Yeah, they both have the same hardware these days, but the way the sof= tware manages things is so much better on the Mac. I remember using a Mac = many years ago and everything from top to bottom had a consistent look and = feel. On the PC every program is in it's own world with unique fonts, size= s and windows. > >=20 > > I had this machine fairly tuned up and could get most things done witho= ut eye strain and yet still got to treat the display as if it could show mo= re than one window at a time. Then I fired up an HDL tool and the fonts ar= e all so small it was impossible to read them without surgeon's magnifiers.= So I finally gave in and went for the Windows screen adjustment. Seems I= already had it set to 125%. So I thought 150% might do well... adjust, re= boot and the screen looked like I had dropped the resolution to 1024 instea= d of 1920 pixels wide. Everything was so huge! Ok, so I backed that off t= o 135% and it seems to be a bit better, the new app can be read with only a= bit of eye strain. But now I have to go into every app and tweak details = to get it to look right again. > >=20 > > On the Mac, if I could read one app, I could read them all! Too bad so= much engineering software won't run on the Mac. > >=20 > > So how does Linux handle things like font sizes? I'm thinking it is re= ally the wild west or it forces the user to manually muck with all the sett= ings on every program. At least I can get a lot more engineering tools to = run under Linux than on the Mac. I really do need to try Linux sometime. > >=20 >=20 > Generally pretty well. I've been daily driving on Linux machines for abo= ut a=20 > decade now and would never consider going back. >=20 > That said, Modelsim on Linux does in fact have a font problem that requir= es=20 > manually mucking with hidden settings in an undocumented way, otherwise i= t's=20 > like you're trying to read source from orbit. I remember when I was young I was able to read anything, anywhere, in any l= ight. I have one eye highly astigmatic which my brain uses, but does not r= ely on. As I've gotten older it has been a bit of a strain to compensate w= ith glasses. I've now reached the point where I just can't read the durn c= omputer unless the fonts are significantly bigger than standard. Some prog= rams cooperate, but often only in the text display windows. Various contro= ls are still very hard to make out. =20 I'm pretty sure all that is handled cleanly in the Mac. It sounds like Lin= ux is as I suspected, some programs work well with the settings and others = don't... not unlike Windows. =20 I keep saying I'm going to give Linux a try. I have one thing I need to ge= t done today. After that I'll try dragging out a 15 inch laptop I've got a= nd seeing if I can make it dual boot. Any suggestions as to which Linux wo= uld be optimal for running CAD tools? Also, I have a little experience wit= h Raspbian on the rPi. I don't know if that should be a factor or not. Is= there really much difference between Linuxes from a user perspective?=20 --=20 Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209Article: 161610
On 08/01/2020 18:55, Rick C wrote: > On Wednesday, January 8, 2020 at 12:29:20 PM UTC-5, Rob Gaddi wrote: >> On 1/7/20 8:00 PM, Rick C wrote: >>> I bet the Apple still have a huge leg up on PCs when it comes to >>> displays. Yeah, they both have the same hardware these days, but >>> the way the software manages things is so much better on the Mac. >>> I remember using a Mac many years ago and everything from top to >>> bottom had a consistent look and feel. On the PC every program >>> is in it's own world with unique fonts, sizes and windows. >>> >>> I had this machine fairly tuned up and could get most things done >>> without eye strain and yet still got to treat the display as if >>> it could show more than one window at a time. Then I fired up an >>> HDL tool and the fonts are all so small it was impossible to read >>> them without surgeon's magnifiers. So I finally gave in and went >>> for the Windows screen adjustment. Seems I already had it set to >>> 125%. So I thought 150% might do well... adjust, reboot and the >>> screen looked like I had dropped the resolution to 1024 instead >>> of 1920 pixels wide. Everything was so huge! Ok, so I backed >>> that off to 135% and it seems to be a bit better, the new app can >>> be read with only a bit of eye strain. But now I have to go into >>> every app and tweak details to get it to look right again. >>> >>> On the Mac, if I could read one app, I could read them all! Too >>> bad so much engineering software won't run on the Mac. >>> >>> So how does Linux handle things like font sizes? I'm thinking it >>> is really the wild west or it forces the user to manually muck >>> with all the settings on every program. At least I can get a lot >>> more engineering tools to run under Linux than on the Mac. I >>> really do need to try Linux sometime. >>> >> >> Generally pretty well. I've been daily driving on Linux machines >> for about a decade now and would never consider going back. >> >> That said, Modelsim on Linux does in fact have a font problem that >> requires manually mucking with hidden settings in an undocumented >> way, otherwise it's like you're trying to read source from orbit. > > I remember when I was young I was able to read anything, anywhere, in > any light. I have one eye highly astigmatic which my brain uses, but > does not rely on. As I've gotten older it has been a bit of a strain > to compensate with glasses. I've now reached the point where I just > can't read the durn computer unless the fonts are significantly > bigger than standard. Some programs cooperate, but often only in the > text display windows. Various controls are still very hard to make > out. > > I'm pretty sure all that is handled cleanly in the Mac. It sounds > like Linux is as I suspected, some programs work well with the > settings and others don't... not unlike Windows. > > I keep saying I'm going to give Linux a try. I have one thing I need > to get done today. After that I'll try dragging out a 15 inch laptop > I've got and seeing if I can make it dual boot. Any suggestions as > to which Linux would be optimal for running CAD tools? Also, I have > a little experience with Raspbian on the rPi. I don't know if that > should be a factor or not. Is there really much difference between > Linuxes from a user perspective? > I can't say how well any particular program will work on Linux - that depends on the program. But I can give you a few general points. GUI software on Linux, like on the Mac, almost invariably uses a graphics toolkit - GTK and QT are the most common for modern code, along with Java toolkits. (Several others, such as TK/TCL or wxWidgits, build on top of these.) A key point about the window layout for most of these is that it is done with boxes and sizers that re-size according to the size of the contents. That means if you have a window or a dialog box and choose a bigger font, the widgets and the boxes all grow to fit. So on these systems, most programs (but not all) work fine when you scale the fonts or choose "high dots per inch" settings. This is different from Windows base API where positions and sizes of widgets is generally done using pixel counts. When you try to scale the font sizes, you get a mess because the text no longer fits in the dialog widgets. This is a lot less of a problem than it used to be, as more programs on Windows also use decent toolkits, but you will see it. So if you are going to use a high DPI screen, or just increase the size of the fonts to fit ageing eyes (none of us are getting younger), a modern Linux will be as good as a Mac (i.e., mostly fine, but with a risk of a few exceptions) and better than Windows. Under the hood, Linux and Macs work in quite a similar fashion - both are *nix systems. On the gui side, Linux is vastly more configurable than either MacOS or Windows, with dozens of different desktops to choose from. This is, of course, both a blessing and a curse. A huge difference between Windows and Linux is that in Windows, you usually get software by going to the website for the software, downloading it, and installing it. You update it by going to the website, noticing there is a new version, downloading it, and installing it. With Linux, you get the solid majority of your software from your distribution - you find it in your package manager, click the checkbox for the software you want, and the package manager handles the rest. And it will tell you when there are new versions and easily update them (but only if and when you want it to!). For software in the distribution, this is hugely easier than the Windows way - for software that is not part of the distribution, or when you want odd versions, it can be more difficult. As for Linux distributions, there are /many/. Most are somewhat niche - if you want something for security testing, or for audio-visual work, or for tiny systems, or for "compile everything yourself" aficionados, there are distributions for you. For the more "normal" user, there are basically two groups - Red Hat and Debian. Red Hat is a big favourite for servers and workstations, and is often bought with support contracts. CentOS is a free and compatible version. Debian is all free, and has a massive software base. The emphasis on free (as in "free speech", not "free beer") is not always the best for users, however. So it is common to use derivatives that are based on Debian, but include other software that makes life easier. Ubuntu is the most well-known of these. Linux Mint is a derivative of Ubuntu which is becoming increasingly common. (Knowing the chain of ancestry of a distribution helps a lot when searching for help or tips - if you have Linux Mint, and can't find information you want when searching for "How do I do X in Linux Mint?", you can try searching for Ubuntu or Debian instead, and the answer will probably still apply.) So which should you choose? The main Linux software is found in all of these, but third-party software (such as FPGA design tools) often specifies only a few distributions - typically Red Hat and Ubuntu. It is almost always fine to use a derivative of these. My strong recommendation is Linux Mint. Ubuntu's desktop has always struck me as ugly and intrusive - Windows does not have a monopoly on making silly desktops that get in your way. Mint's desktop will make you feel "this looks like a computer, and works like a computer". Mint has two main desktops by default - Mate and Cinnamon. Cinnamon is snazzier, with cooler effects - if you like that sort of thing. Mate is simpler, though older, and makes it a lot easier to simply get on with your work. So that is my choice, and my recommendation. <https://www.linuxmint.com/download.php> When you are running a program, there is little significant difference between the distributions. But there are differences in the package managers, and the choice of software they come with, and the choice of desktop. (You can always install other desktops, but it's easier to have one you like out of the box.) Rasbian is a Debian variant, so much of it is the same as Linux Mint. But Rasbian has a lighter and simpler desktop, which is a bit crude and limited in comparison to Mate. (For servers, my preference is pure Debian, if that is of interest to you.) Remember, you can always try out a new OS in a virtual machine. I have found Virtual Box very good. (And I've seen Windows programs running faster inside Virtual Box on a Linux host than they ran on native Windows on the same hardware.)Article: 161611
On Wed, 8 Jan 2020 09:55:51 -0800 (PST) Rick C <gnuarm.deletethisbit@gmail.com> wrote: [...] > > I keep saying I'm going to give Linux a try. I have one thing I need to get done today. After that I'll try dragging out a 15 inch laptop I've got and seeing if I can make it dual boot. Any suggestions as to which Linux would be optimal for running CAD tools? Also, I have a little experience with Raspbian on the rPi. I don't know if that should be a factor or not. Is there really much difference between Linuxes from a user perspective? Xilinx specify Red Hat, so the 'community' version CentOS would likely be best. I use (very) old version, CentOS 6, in separate virtual machines for Xilinx ISE, Lattice Diamond, and Lattice iCE40 tool chains. ISE 14.7 needed a 30GB disk image to complete installation. Lattice Diamond was installed in 12GB, and Lattice iCE40 7GB. Shared folders make it possible to keep or backup source to the host system. My 1600*900 laptop screen is tight with most tool chain GUIs, so I use an external monitor, and/or multiple (full desktop size) workspaces. Or use toolchain scripting to eliminate the GUI. Jan Coombs --Article: 161612
Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> wrote: > Xilinx specify Red Hat, so the 'community' version CentOS would > likely be best. If you're running CAD tools, I'd strongly suggest CentOS. It's based on Red Hat Enterprise Linux which is supported by most tool vendors (Synopsys/Cadence/Mentor/Intel-Altera/Xilinx). Other distros like Debian (Raspbian) or Ubuntu have patchier support, although it's getting better. We're primarily an Ubuntu shop, so I've got quite proficient at the hacks necessary to run tools on unsupported Linux distros - although the student who turned up with Mageia (based on Arch Linux) caused some head scratching. For a simple life, I'd recommend running whatever distro and version the tool vendor recommends in a VM. Run multiple VMs with different versions if you have to. It'll make the setup pain a lot easier. TheoArticle: 161613
Thanks for the replies. I've got a new Flash USB stick around here somewhere. I need to pull it out and install a Linux on it. -- Rick C. -- Get 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209Article: 161614
On 09/01/2020 02:35, Rick C wrote: > Thanks for the replies. I've got a new Flash USB stick around here somewhere. I need to pull it out and install a Linux on it. > Note that for many distros, you can try them "live" from the USB stick without any installation. If you've plenty of ram and a fast USB stick (a USB 3 stick), this will should be good enough to test the system. You can even install programs - it all goes in ram, rather than on the USB stick, and it all disappears when you reboot.Article: 161615
On Wednesday, January 8, 2020 at 10:00:25 PM UTC, David Brown wrote: > GUI software on Linux, like on the Mac, almost invariably uses a=20 > graphics toolkit - GTK and QT are the most common for modern code, along= =20 > with Java toolkits. (Several others, such as TK/TCL or wxWidgits, build= =20 > on top of these.) =20 I believe TK/Tcl uses XWindows on Linux, and for Windows uses the basic Win= dows Widgets. Modelsim has a TK GUI. I think Vivado is a widget set based o= n java swing, it might be JGoodies but I can't quite recall now 100%. I thi= nk Synplify, Quartus and Diamond are QT, but I'm basing that on that they d= on't look like TK or Java :) Although now I think about it, the Quartus IP = GUI I think is Java Swing, and Diamond IP GUI is TK.Article: 161616
On Friday, January 10, 2020 at 1:33:22 PM UTC-5, pau...@googlemail.com wrot= e: > On Wednesday, January 8, 2020 at 10:00:25 PM UTC, David Brown wrote: >=20 > > GUI software on Linux, like on the Mac, almost invariably uses a=20 > > graphics toolkit - GTK and QT are the most common for modern code, alon= g=20 > > with Java toolkits. (Several others, such as TK/TCL or wxWidgits, buil= d=20 > > on top of these.) =20 >=20 > I believe TK/Tcl uses XWindows on Linux, and for Windows uses the basic W= indows Widgets. Modelsim has a TK GUI. I think Vivado is a widget set based= on java swing, it might be JGoodies but I can't quite recall now 100%. I t= hink Synplify, Quartus and Diamond are QT, but I'm basing that on that they= don't look like TK or Java :) Although now I think about it, the Quartus I= P GUI I think is Java Swing, and Diamond IP GUI is TK. So under Windows 10 is there another way of enlarging all the text in the D= iamond display (hopefully along with the size of the fields they are in)? = Using the Windows zoom capability seems to enlarge many things far too much= before the Diamond window is large enough.=20 I was pretty happy with 125% zoom before I opened the diamond window. Now = everything looks clownishly large at 135%. At least one of my common apps = is a bit fuzzy. I'm wondering if it is being zoomed by simply enlarging th= e pixels it is drawing. =20 --=20 Rick C. -+ Get 1,000 miles of free Supercharging -+ Tesla referral code - https://ts.la/richard11209Article: 161617
On Saturday, January 11, 2020 at 7:27:37 PM UTC, Rick C wrote: > So under Windows 10 is there another way of enlarging all the text in the= Diamond display (hopefully along with the size of the fields they are in)?= Using the Windows zoom capability seems to enlarge many things far too mu= ch before the Diamond window is large enough.=20 >=20 I don't know what the answer to this is. The reason why your Mac worked nic= ely is probably because all your mac apps used point fonts rather than pixe= l fonts and SVG graphics instead of pngs. So irrespective of DPI, everythin= g's nice and readable. A lot of engineering software on PCs still don't do = this, both on Windows and Linux. Windows at least has the scaling setting. = I believe some Linux distros have some kind of setting for high DPI screens= but the Debian that I'm using now doesn't as far as I know, so I get small= graphics/text on my high DPI laptop screen, and there's no easy way that I= know of to get round that. A lot of FPGA tools still need to improve, ie don't use PNGs and don't use = pixel fonts, and make use of the DPI settings provided by the host system. = Most widget sets provide some sort of support for varying DPI, including QT= , Swing and TK. At least with FPGA tools however you don't _need_ to use the GUI because yo= u can script them. Although then you need to be able to use Tcl and go thro= ugh their documentation to write the scripts in the first place. Where I've= worked, mostly this is how things get done. FPGA tools can dump out simple scripts for you. I though have some personal= scripts (that I don't use at work) here https://www.p-code.org/ttask, and = there are similar tools available on github, for example see https://github= .com/olofk/fusesoc and https://github.com/olofk/edalize. You can do some nice things with scripts. For example with ttask for a desi= gn I split my testbenches up so each testbench is a subset of all the tests= that I need to perform and then I tell the tool which testbenches to run a= nd how many to run concurrently. It's a good way to speed up testbenches be= cause you can get your PC up to 100% load and get your tests done in the sh= ortest time. At home I have the freely available Altera Modelsim And Xilinx= XSim, and both of those let you do that. =20 =20Article: 161618
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? > > In a former position I pondered this very question. > > What is firmer than firmware (the term they used to describe code > designs for micro-controllers) but softer than hardware (designs using > wires to connect together various components)? > > The answer I came up with was "stiffware". > > The problem is that there are elements of both in FPGA code, or at least > there can be. And depending on how you write your VHDL it may resemble > one more than the other. > > James. "Stiffware" I love it!!Article: 161619
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. JonArticle: 161620
On Wednesday, January 29, 2020 at 3:07:11 PM UTC-5, Jon Elson wrote: > On Mon, 27 Jan 2020 10:28:39 -0800, ritchiew wrote: >=20 > > 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=20 > firmware is very wrong when talking to less-technical folks. >=20 > Jon I think "configuration" would be equivalent to the machine code that is pro= duced by a standard compiler for CPUs. The OP is asking what to call the s= ource code. In PCs and other typical computers it is "software". In embed= ded applications it is "firmware", mainly because it is loaded into a write= only memory (or write mostly). So what name to use for programming that i= s for configuring hardware? =20 I think I'm in favor of "hardware"... oh, what, that's already used... lol= =20 Firmware is as good as any term. I'm ok with calling it software. =20 --=20 Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209Article: 161621
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... Regards, MarkArticle: 161622
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? -- Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209Article: 161623
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. TheoArticle: 161624
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: > >=20 > > > On Monday, February 20, 2006 at 1:50:15 PM UTC-8, James Morrison wrot= e: > > >> On Mon, 2006-02-20 at 10:18 -0800, Marko wrote: > > >> > Traditionally, firmware was defined as software that resided in RO= M. > > >> > 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= =20 > > firmware is very wrong when talking to less-technical folks. >=20 > I'm uncomfortable with the use of 'firmware', because FPGAs frequently ha= ve > 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, som= e > 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 y= ou > might expect software people to apply for the job, for instance. >=20 > Another term used for the hardware is 'bitstream' - not very descriptive, > although it does imply the hardware-blockbox overtones to it. >=20 > If you're talking in general terms about the lump of data loaded from fla= sh > on boot, used to make the product usable, without any distinction of whet= her > it's hardware or software, then maybe firmware works slightly better. >=20 > Theo I guess my interest is in a label for the program as written in the languag= e, the HDL. I don't call that a bitstream. The bitstream is what gets loa= ded into the FPGA. I write software or firmware. I've never gotten used t= o the term "gateware" but it would be fine if that is what ends up being ac= cepted ultimately. =20 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 be= ing made? =20 --=20 Rick C. -- Get 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209
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