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 6/9/2015 10:11 AM, Yaman Umuroglu wrote:
> On Monday, June 8, 2015 at 12:45:50 AM UTC+2, Leonardo Capossio wrote:
>> Hello all, I would like to know which open or free HLS (High Level Synthesis) tools are gaining widespread use, or are more likely to survive, because at the time there seems to be too many, and the advantages of each of them are not quite clear. The HLS we are talking about should generate synthesizable Verilog or VHDL for multiple architectures (at least Xilinx/Altera).
>>
>> Learning a new language is cumbersome, hence I would like to fill my head with only a select few that have promising future.
>>
>> I have read this comparison (http://upcommons.upc.edu/e-prints/bitstream/2117/25882/1/Cristal.pdf), which made my think that Chisel might be the way to go.
>
> Hi Leonardo,
>
> I really like Chisel and have used it for two FPGA compute projects so far by either directly using the generated Verilog, or wrapping it as IP cores for importing into Vivado. However, I wouldn't really call it "HLS" -- while it gives higher productivity compared to Verilog or VHDL, Chisel code is still very close to RTL and requires RTL-like thinking.
I don't think RTL is the correct term here but the point
is you feel it requires a lower-lower level abstraction
than you would like. Chisel is a bread of the functional
language based HDLs. You start with a basic building block
(function, or register in HDL) and scale-up quickly - at
least that is the idea (?).
> While I've only looked at it briefly myself, LegUp seems to be a worthy open/free HLS alternative that is actively maintained (http://legup.eecg.utoronto.ca/). I don't think they support Xilinx for the time being, but the abstractions made by the framework should make it straightforward to port to Xilinx FPGAs (i.e defining the primitives and their relative cost).
I will never understand how any C based language will be
considered HLS! Saw a funny tweet the other day:
Computer Science: "In low-level languages like C"
Computer Engineering: "In high-level languages like C"
Regards,
Chris
Article: 157976El martes, 9 de junio de 2015, 12:11:54 (UTC-3), Yaman Umuroglu escribi=F3: > On Monday, June 8, 2015 at 12:45:50 AM UTC+2, Leonardo Capossio wrote: > > Hello all, I would like to know which open or free HLS (High Level Synt= hesis) tools are gaining widespread use, or are more likely to survive, bec= ause at the time there seems to be too many, and the advantages of each of = them are not quite clear. The HLS we are talking about should generate synt= hesizable Verilog or VHDL for multiple architectures (at least Xilinx/Alter= a). > >=20 > > Learning a new language is cumbersome, hence I would like to fill my he= ad with only a select few that have promising future. > >=20 > > I have read this comparison (http://upcommons.upc.edu/e-prints/bitstrea= m/2117/25882/1/Cristal.pdf), which made my think that Chisel might be the w= ay to go. >=20 > Hi Leonardo, >=20 > I really like Chisel and have used it for two FPGA compute projects so fa= r by either directly using the generated Verilog, or wrapping it as IP core= s for importing into Vivado. However, I wouldn't really call it "HLS" -- wh= ile it gives higher productivity compared to Verilog or VHDL, Chisel code i= s still very close to RTL and requires RTL-like thinking. > While I've only looked at it briefly myself, LegUp seems to be a worthy o= pen/free HLS alternative that is actively maintained (http://legup.eecg.uto= ronto.ca/). I don't think they support Xilinx for the time being, but the a= bstractions made by the framework should make it straightforward to port to= Xilinx FPGAs (i.e defining the primitives and their relative cost). >=20 > Yaman Yes, I have already looked at Chisel, and I do agree with you. It seems to = have good performance, but it still is very RTL-like, and is not as capable= (or supported) as VHDL or Verilog at RTL-level (for example having specifi= c architecture instances like RAMs, ROMs or even more important I/O primiti= ves is difficult). It just seems like the effort to learn this language com= pared to the abstraction/easiness at algorithm level is not very high. LegUp on the other hand, would provide more abstraction, but it has sub-par= results (according to the paper I posted it beats the software implementat= ion in performance in most cases, but is always bested by far by other lang= uages).Article: 157977
El martes, 9 de junio de 2015, 13:39:23 (UTC-3), Christopher Felton escribi= =F3: > On 6/9/2015 10:11 AM, Yaman Umuroglu wrote: > > On Monday, June 8, 2015 at 12:45:50 AM UTC+2, Leonardo Capossio wrote: > >> Hello all, I would like to know which open or free HLS (High Level Syn= thesis) tools are gaining widespread use, or are more likely to survive, be= cause at the time there seems to be too many, and the advantages of each of= them are not quite clear. The HLS we are talking about should generate syn= thesizable Verilog or VHDL for multiple architectures (at least Xilinx/Alte= ra). > >> > >> Learning a new language is cumbersome, hence I would like to fill my h= ead with only a select few that have promising future. > >> > >> I have read this comparison (http://upcommons.upc.edu/e-prints/bitstre= am/2117/25882/1/Cristal.pdf), which made my think that Chisel might be the = way to go. > > > > Hi Leonardo, > > > > I really like Chisel and have used it for two FPGA compute projects so = far by either directly using the generated Verilog, or wrapping it as IP co= res for importing into Vivado. However, I wouldn't really call it "HLS" -- = while it gives higher productivity compared to Verilog or VHDL, Chisel code= is still very close to RTL and requires RTL-like thinking. >=20 > I don't think RTL is the correct term here but the point > is you feel it requires a lower-lower level abstraction > than you would like. Chisel is a bread of the functional > language based HDLs. You start with a basic building block > (function, or register in HDL) and scale-up quickly - at > least that is the idea (?). >=20 > > While I've only looked at it briefly myself, LegUp seems to be a worthy= open/free HLS alternative that is actively maintained (http://legup.eecg.u= toronto.ca/). I don't think they support Xilinx for the time being, but the= abstractions made by the framework should make it straightforward to port = to Xilinx FPGAs (i.e defining the primitives and their relative cost). >=20 > I will never understand how any C based language will be > considered HLS! Saw a funny tweet the other day: >=20 > Computer Science: "In low-level languages like C" > Computer Engineering: "In high-level languages like C" >=20 > Regards, > Chris Well, the wikipedia page defines it so (http://en.wikipedia.org/wiki/High-l= evel_synthesis), not saying this is the ultimate authority in the matter, b= ut you at least have to counter this assertion with something better than a= tweet. I guess C is low-level in computer science because you can actually trace m= ost of the code one-to-one or one-to-many from C to assembler. In hardware = description this is far more difficult to do, some statements are not liter= ally translated into HDL code, but rather interpreted, and many assumptions= are made. They are different fields. Keep in mind C will not be the highes= t HDL language ever, but the first of them (or one of the first).Article: 157978
On 6/9/2015 12:14 PM, Leonardo Capossio wrote: > El martes, 9 de junio de 2015, 13:39:23 (UTC-3), Christopher Felton escribió: >> On 6/9/2015 10:11 AM, Yaman Umuroglu wrote: >>> On Monday, June 8, 2015 at 12:45:50 AM UTC+2, Leonardo Capossio wrote: >>>> Hello all, I would like to know which open or free HLS (High Level Synthesis) tools are gaining widespread use, or are more likely to survive, because at the time there seems to be too many, and the advantages of each of them are not quite clear. The HLS we are talking about should generate synthesizable Verilog or VHDL for multiple architectures (at least Xilinx/Altera). >>>> >>>> Learning a new language is cumbersome, hence I would like to fill my head with only a select few that have promising future. >>>> >>>> I have read this comparison (http://upcommons.upc.edu/e-prints/bitstream/2117/25882/1/Cristal.pdf), which made my think that Chisel might be the way to go. >>> >>> Hi Leonardo, >>> >>> I really like Chisel and have used it for two FPGA compute projects so far by either directly using the generated Verilog, or wrapping it as IP cores for importing into Vivado. However, I wouldn't really call it "HLS" -- while it gives higher productivity compared to Verilog or VHDL, Chisel code is still very close to RTL and requires RTL-like thinking. >> >> I don't think RTL is the correct term here but the point >> is you feel it requires a lower-lower level abstraction >> than you would like. Chisel is a bread of the functional >> language based HDLs. You start with a basic building block >> (function, or register in HDL) and scale-up quickly - at >> least that is the idea (?). >> >>> While I've only looked at it briefly myself, LegUp seems to be a worthy open/free HLS alternative that is actively maintained (http://legup.eecg.utoronto.ca/). I don't think they support Xilinx for the time being, but the abstractions made by the framework should make it straightforward to port to Xilinx FPGAs (i.e defining the primitives and their relative cost). >> >> I will never understand how any C based language will be >> considered HLS! Saw a funny tweet the other day: >> >> Computer Science: "In low-level languages like C" >> Computer Engineering: "In high-level languages like C" >> >> Regards, >> Chris > > Well, the wikipedia page defines it so (http://en.wikipedia.org/wiki/High-level_synthesis), not saying this is the ultimate authority in the matter, but you at least have to counter this assertion with something better than a tweet. Why? I wasn't trying to correct anything just stating how I am dumbfounded at the term! Do you disagree with low-high statement? I think it is rather fitting :) If this is the unfortunate state of terminology, what do we call synthesis of non C languages? Ultra-high, up-in-smoke, etc. etc. I think this is a better description: "algorithm to gates" http://mesl.ucsd.edu/gupta/pubs/HLSRetrospective08Rev3.pdf (there is a book with a similar title) The HLS term should be language agnostic, it is silly to tie it to C based languages! > > I guess C is low-level in computer science because you can actually trace most of the code one-to-one or one-to-many from C to assembler. In hardware description this is far more difficult to do, some statements are not literally translated into HDL code, but rather interpreted, and many assumptions are made. They are different fields. Keep in mind C will not be the highest HDL language ever, but the first of them (or one of the first). > Probably because the name was coined in the early 90s (or earlier). In my opinion C synthesis is pointless. I think these guys kinda got it right (but they based their language on C constructs also - confusing): https://blog.synflow.com/numbers-dont-lie-there-is-virtually-no-interest-in-high-level-synthesis/ Regards, ChrisArticle: 157979
El martes, 9 de junio de 2015, 15:08:40 (UTC-3), Christopher Felton escribi= =F3: > On 6/9/2015 12:14 PM, Leonardo Capossio wrote: > > El martes, 9 de junio de 2015, 13:39:23 (UTC-3), Christopher Felton esc= ribi=F3: > >> On 6/9/2015 10:11 AM, Yaman Umuroglu wrote: > >>> On Monday, June 8, 2015 at 12:45:50 AM UTC+2, Leonardo Capossio wrote= : > >>>> Hello all, I would like to know which open or free HLS (High Level S= ynthesis) tools are gaining widespread use, or are more likely to survive, = because at the time there seems to be too many, and the advantages of each = of them are not quite clear. The HLS we are talking about should generate s= ynthesizable Verilog or VHDL for multiple architectures (at least Xilinx/Al= tera). > >>>> > >>>> Learning a new language is cumbersome, hence I would like to fill my= head with only a select few that have promising future. > >>>> > >>>> I have read this comparison (http://upcommons.upc.edu/e-prints/bitst= ream/2117/25882/1/Cristal.pdf), which made my think that Chisel might be th= e way to go. > >>> > >>> Hi Leonardo, > >>> > >>> I really like Chisel and have used it for two FPGA compute projects s= o far by either directly using the generated Verilog, or wrapping it as IP = cores for importing into Vivado. However, I wouldn't really call it "HLS" -= - while it gives higher productivity compared to Verilog or VHDL, Chisel co= de is still very close to RTL and requires RTL-like thinking. > >> > >> I don't think RTL is the correct term here but the point > >> is you feel it requires a lower-lower level abstraction > >> than you would like. Chisel is a bread of the functional > >> language based HDLs. You start with a basic building block > >> (function, or register in HDL) and scale-up quickly - at > >> least that is the idea (?). > >> > >>> While I've only looked at it briefly myself, LegUp seems to be a wort= hy open/free HLS alternative that is actively maintained (http://legup.eecg= .utoronto.ca/). I don't think they support Xilinx for the time being, but t= he abstractions made by the framework should make it straightforward to por= t to Xilinx FPGAs (i.e defining the primitives and their relative cost). > >> > >> I will never understand how any C based language will be > >> considered HLS! Saw a funny tweet the other day: > >> > >> Computer Science: "In low-level languages like C" > >> Computer Engineering: "In high-level languages like C" > >> > >> Regards, > >> Chris > > > > Well, the wikipedia page defines it so (http://en.wikipedia.org/wiki/Hi= gh-level_synthesis), not saying this is the ultimate authority in the matte= r, but you at least have to counter this assertion with something better th= an a tweet. >=20 > Why? I wasn't trying to correct anything just stating > how I am dumbfounded at the term! Do you disagree with > low-high statement? I think it is rather fitting :) >=20 > If this is the unfortunate state of terminology, what do > we call synthesis of non C languages? Ultra-high, > up-in-smoke, etc. etc. >=20 > I think this is a better description: "algorithm to gates" > http://mesl.ucsd.edu/gupta/pubs/HLSRetrospective08Rev3.pdf > (there is a book with a similar title) >=20 > The HLS term should be language agnostic, it is silly to > tie it to C based languages! >=20 The tweet is true and points at a funny fact. But that doesn't mean that C = is not a high level language when talking about synthesis. The HLS term IS agnostic, the wikipedia article is only focusing about C wh= ich is also rather biased (but probably because it is a well known language= , and at the time of creation C was considered high level), but mentions: "= High-level synthesis (HLS), sometimes referred to as C synthesis, electroni= c system-level (ESL) synthesis, algorithmic synthesis, or behavioral synthe= sis...". It even includes your "algorithmic" preference for the term as "al= gorithmic synthesis". > > > > I guess C is low-level in computer science because you can actually tra= ce most of the code one-to-one or one-to-many from C to assembler. In hardw= are description this is far more difficult to do, some statements are not l= iterally translated into HDL code, but rather interpreted, and many assumpt= ions are made. They are different fields. Keep in mind C will not be the hi= ghest HDL language ever, but the first of them (or one of the first). > > >=20 > Probably because the name was coined in the early 90s > (or earlier). In my opinion C synthesis is pointless. >=20 > I think these guys kinda got it right (but they based > their language on C constructs also - confusing): > https://blog.synflow.com/numbers-dont-lie-there-is-virtually-no-interest-= in-high-level-synthesis/ >=20 > Regards, > Chris The fact that there are less google searches is a fact that can't be ignore= d, but it does not mean it is the end. Someone will get it right eventually= , and the thing will become very popular, probably at the same time that FP= GAs become very popular (mainstream I mean, like arduino with microcontroll= ers). If a certain person (or company) is going to make a genius invention = (or lead it) in the next two years, then he is thinking about this inventio= n starting from now, or even before (and he is certainly at that point very= familiar with the problem that he will be tackling). I cannot point any so= urce, but I think it makes at least more than 50% of the cases (the rest ju= st happened to stumble into greatness by chance).Article: 157980
El martes, 9 de junio de 2015, 17:00:23 (UTC-3), Leonardo Capossio escribi= =F3: > El martes, 9 de junio de 2015, 15:08:40 (UTC-3), Christopher Felton escri= bi=F3: > > On 6/9/2015 12:14 PM, Leonardo Capossio wrote: > > > El martes, 9 de junio de 2015, 13:39:23 (UTC-3), Christopher Felton e= scribi=F3: > > >> On 6/9/2015 10:11 AM, Yaman Umuroglu wrote: > > >>> On Monday, June 8, 2015 at 12:45:50 AM UTC+2, Leonardo Capossio wro= te: > > >>>> Hello all, I would like to know which open or free HLS (High Level= Synthesis) tools are gaining widespread use, or are more likely to survive= , because at the time there seems to be too many, and the advantages of eac= h of them are not quite clear. The HLS we are talking about should generate= synthesizable Verilog or VHDL for multiple architectures (at least Xilinx/= Altera). > > >>>> > > >>>> Learning a new language is cumbersome, hence I would like to fill = my head with only a select few that have promising future. > > >>>> > > >>>> I have read this comparison (http://upcommons.upc.edu/e-prints/bit= stream/2117/25882/1/Cristal.pdf), which made my think that Chisel might be = the way to go. > > >>> > > >>> Hi Leonardo, > > >>> > > >>> I really like Chisel and have used it for two FPGA compute projects= so far by either directly using the generated Verilog, or wrapping it as I= P cores for importing into Vivado. However, I wouldn't really call it "HLS"= -- while it gives higher productivity compared to Verilog or VHDL, Chisel = code is still very close to RTL and requires RTL-like thinking. > > >> > > >> I don't think RTL is the correct term here but the point > > >> is you feel it requires a lower-lower level abstraction > > >> than you would like. Chisel is a bread of the functional > > >> language based HDLs. You start with a basic building block > > >> (function, or register in HDL) and scale-up quickly - at > > >> least that is the idea (?). > > >> > > >>> While I've only looked at it briefly myself, LegUp seems to be a wo= rthy open/free HLS alternative that is actively maintained (http://legup.ee= cg.utoronto.ca/). I don't think they support Xilinx for the time being, but= the abstractions made by the framework should make it straightforward to p= ort to Xilinx FPGAs (i.e defining the primitives and their relative cost). > > >> > > >> I will never understand how any C based language will be > > >> considered HLS! Saw a funny tweet the other day: > > >> > > >> Computer Science: "In low-level languages like C" > > >> Computer Engineering: "In high-level languages like C" > > >> > > >> Regards, > > >> Chris > > > > > > Well, the wikipedia page defines it so (http://en.wikipedia.org/wiki/= High-level_synthesis), not saying this is the ultimate authority in the mat= ter, but you at least have to counter this assertion with something better = than a tweet. > >=20 > > Why? I wasn't trying to correct anything just stating > > how I am dumbfounded at the term! Do you disagree with > > low-high statement? I think it is rather fitting :) > >=20 > > If this is the unfortunate state of terminology, what do > > we call synthesis of non C languages? Ultra-high, > > up-in-smoke, etc. etc. > >=20 > > I think this is a better description: "algorithm to gates" > > http://mesl.ucsd.edu/gupta/pubs/HLSRetrospective08Rev3.pdf > > (there is a book with a similar title) > >=20 > > The HLS term should be language agnostic, it is silly to > > tie it to C based languages! > >=20 >=20 > The tweet is true and points at a funny fact. But that doesn't mean that = C is not a high level language when talking about synthesis. >=20 > The HLS term IS agnostic, the wikipedia article is only focusing about C = which is also rather biased (but probably because it is a well known langua= ge, and at the time of creation C was considered high level), but mentions:= "High-level synthesis (HLS), sometimes referred to as C synthesis, electro= nic system-level (ESL) synthesis, algorithmic synthesis, or behavioral synt= hesis...". It even includes your "algorithmic" preference for the term as "= algorithmic synthesis". >=20 > > > > > > I guess C is low-level in computer science because you can actually t= race most of the code one-to-one or one-to-many from C to assembler. In har= dware description this is far more difficult to do, some statements are not= literally translated into HDL code, but rather interpreted, and many assum= ptions are made. They are different fields. Keep in mind C will not be the = highest HDL language ever, but the first of them (or one of the first). > > > > >=20 > > Probably because the name was coined in the early 90s > > (or earlier). In my opinion C synthesis is pointless. > >=20 > > I think these guys kinda got it right (but they based > > their language on C constructs also - confusing): > > https://blog.synflow.com/numbers-dont-lie-there-is-virtually-no-interes= t-in-high-level-synthesis/ > >=20 > > Regards, > > Chris >=20 >=20 > The fact that there are less google searches is a fact that can't be igno= red, but it does not mean it is the end. Someone will get it right eventual= ly, and the thing will become very popular, probably at the same time that = FPGAs become very popular (mainstream I mean, like arduino with microcontro= llers). If a certain person (or company) is going to make a genius inventio= n (or lead it) in the next two years, then he is thinking about this invent= ion starting from now, or even before (and he is certainly at that point ve= ry familiar with the problem that he will be tackling). I cannot point any = source, but I think it makes at least more than 50% of the cases (the rest = just happened to stumble into greatness by chance). For the record the interest in high-level synthesis is slowly decreasing bu= t saw an increase starting from 2012. But MORE interesting is the fact that= FPGA alone as a search term is decreasing since 2004, and I don't think FP= GA are going obsolete any time soon. Turns out that this "EDA" developer ar= ticle was really biased (https://www.google.com/trends/explore#q=3Dfpga&cmp= t=3Dq&tz=3D). It is clear that HLS is not a mainstream search term, but it = is not over (and by HLS, I am talking about any language that infers VHDL/V= erilog or gate-level-description)Article: 157981
> Jan did DVB-S in CPU software with VGA output. That would be nice to see! Do you have a link?Article: 157982
On a sunny day (Tue, 9 Jun 2015 22:31:08 +0100) it happened "Tomas D." <mailsoc@gmial.com> wrote in <ml7lsf$6lm$1@dont-email.me>: >> Jan did DVB-S in CPU software with VGA output. > >That would be nice to see! Do you have a link? Are you talking about me? Dunno about 'VGA' output, but I did a DVB-S encoder + transmitter on the Raspberry Pi. There is a guy who made test cards using the graphics card, but that only works for pre-encoded still pictures, receivin gan harmonic IIRC. Sort of a wave form generator... and he did not release source either. So anyways I took the DVB-S spec, wrote the encoder myself, and released source, the first hardware was very simple, but works 100 %: http://panteltje.com/panteltje/raspberry_pi_dvb-s_transmitter/ Funny I was the first one in this side of the universe to release DVB-S encoder source code.. There is a later version now with better hardware. That will be used for sat uplink, well some code etc was posted here, it is sitting on a table waiting for the sat. Credits for the hardware go to a lot of other people, see website. On VGA, so if you need a fast 8 bit DAC, there are 3.Article: 157983
On Tuesday, June 9, 2015 at 10:31:03 PM UTC+2, Leonardo Capossio wrote: > El martes, 9 de junio de 2015, 17:00:23 (UTC-3), Leonardo Capossio escrib= i=F3: > > El martes, 9 de junio de 2015, 15:08:40 (UTC-3), Christopher Felton esc= ribi=F3: > > > On 6/9/2015 12:14 PM, Leonardo Capossio wrote: > > > > El martes, 9 de junio de 2015, 13:39:23 (UTC-3), Christopher Felton= escribi=F3: > > > >> On 6/9/2015 10:11 AM, Yaman Umuroglu wrote: > > > >>> On Monday, June 8, 2015 at 12:45:50 AM UTC+2, Leonardo Capossio w= rote: > > > >>>> Hello all, I would like to know which open or free HLS (High Lev= el Synthesis) tools are gaining widespread use, or are more likely to survi= ve, because at the time there seems to be too many, and the advantages of e= ach of them are not quite clear. The HLS we are talking about should genera= te synthesizable Verilog or VHDL for multiple architectures (at least Xilin= x/Altera). > > > >>>> > > > >>>> Learning a new language is cumbersome, hence I would like to fil= l my head with only a select few that have promising future. > > > >>>> > > > >>>> I have read this comparison (http://upcommons.upc.edu/e-prints/b= itstream/2117/25882/1/Cristal.pdf), which made my think that Chisel might b= e the way to go. > > > >>> > > > >>> Hi Leonardo, > > > >>> > > > >>> I really like Chisel and have used it for two FPGA compute projec= ts so far by either directly using the generated Verilog, or wrapping it as= IP cores for importing into Vivado. However, I wouldn't really call it "HL= S" -- while it gives higher productivity compared to Verilog or VHDL, Chise= l code is still very close to RTL and requires RTL-like thinking. > > > >> > > > >> I don't think RTL is the correct term here but the point > > > >> is you feel it requires a lower-lower level abstraction > > > >> than you would like. Chisel is a bread of the functional > > > >> language based HDLs. You start with a basic building block > > > >> (function, or register in HDL) and scale-up quickly - at > > > >> least that is the idea (?). > > > >> > > > >>> While I've only looked at it briefly myself, LegUp seems to be a = worthy open/free HLS alternative that is actively maintained (http://legup.= eecg.utoronto.ca/). I don't think they support Xilinx for the time being, b= ut the abstractions made by the framework should make it straightforward to= port to Xilinx FPGAs (i.e defining the primitives and their relative cost)= . > > > >> > > > >> I will never understand how any C based language will be > > > >> considered HLS! Saw a funny tweet the other day: > > > >> > > > >> Computer Science: "In low-level languages like C" > > > >> Computer Engineering: "In high-level languages like C" > > > >> > > > >> Regards, > > > >> Chris > > > > > > > > Well, the wikipedia page defines it so (http://en.wikipedia.org/wik= i/High-level_synthesis), not saying this is the ultimate authority in the m= atter, but you at least have to counter this assertion with something bette= r than a tweet. > > >=20 > > > Why? I wasn't trying to correct anything just stating > > > how I am dumbfounded at the term! Do you disagree with > > > low-high statement? I think it is rather fitting :) > > >=20 > > > If this is the unfortunate state of terminology, what do > > > we call synthesis of non C languages? Ultra-high, > > > up-in-smoke, etc. etc. > > >=20 > > > I think this is a better description: "algorithm to gates" > > > http://mesl.ucsd.edu/gupta/pubs/HLSRetrospective08Rev3.pdf > > > (there is a book with a similar title) > > >=20 > > > The HLS term should be language agnostic, it is silly to > > > tie it to C based languages! > > >=20 > >=20 > > The tweet is true and points at a funny fact. But that doesn't mean tha= t C is not a high level language when talking about synthesis. > >=20 > > The HLS term IS agnostic, the wikipedia article is only focusing about = C which is also rather biased (but probably because it is a well known lang= uage, and at the time of creation C was considered high level), but mention= s: "High-level synthesis (HLS), sometimes referred to as C synthesis, elect= ronic system-level (ESL) synthesis, algorithmic synthesis, or behavioral sy= nthesis...". It even includes your "algorithmic" preference for the term as= "algorithmic synthesis". > >=20 > > > > > > > > I guess C is low-level in computer science because you can actually= trace most of the code one-to-one or one-to-many from C to assembler. In h= ardware description this is far more difficult to do, some statements are n= ot literally translated into HDL code, but rather interpreted, and many ass= umptions are made. They are different fields. Keep in mind C will not be th= e highest HDL language ever, but the first of them (or one of the first). > > > > > > >=20 > > > Probably because the name was coined in the early 90s > > > (or earlier). In my opinion C synthesis is pointless. > > >=20 > > > I think these guys kinda got it right (but they based > > > their language on C constructs also - confusing): > > > https://blog.synflow.com/numbers-dont-lie-there-is-virtually-no-inter= est-in-high-level-synthesis/ > > >=20 > > > Regards, > > > Chris > >=20 > >=20 > > The fact that there are less google searches is a fact that can't be ig= nored, but it does not mean it is the end. Someone will get it right eventu= ally, and the thing will become very popular, probably at the same time tha= t FPGAs become very popular (mainstream I mean, like arduino with microcont= rollers). If a certain person (or company) is going to make a genius invent= ion (or lead it) in the next two years, then he is thinking about this inve= ntion starting from now, or even before (and he is certainly at that point = very familiar with the problem that he will be tackling). I cannot point an= y source, but I think it makes at least more than 50% of the cases (the res= t just happened to stumble into greatness by chance). >=20 > For the record the interest in high-level synthesis is slowly decreasing = but saw an increase starting from 2012. But MORE interesting is the fact th= at FPGA alone as a search term is decreasing since 2004, and I don't think = FPGA are going obsolete any time soon. Turns out that this "EDA" developer = article was really biased (https://www.google.com/trends/explore#q=3Dfpga&c= mpt=3Dq&tz=3D). It is clear that HLS is not a mainstream search term, but i= t is not over (and by HLS, I am talking about any language that infers VHDL= /Verilog or gate-level-description) I think the tweet mentioned summarizes this discussion pretty well; there i= s no rigid definition of the "high-level" in high-level synthesis :). For me it's not very high level as long as it is converting between equival= ent abstractions (e.g. Chisel internally creates a directed acyclic graph o= f registers, muxes and operators directly from the description, which can b= e viewed as RTL). Regardless, be it C-to-gates (Vivado HLS/SDSoC) or OpenCL for FPGAs, it see= ms to me that the trend is picking up for "FPGAs for software programmers" = (see also http://arxiv.org/abs/1408.4423). Probably with good reason seeing= how several major players seem to be interested in making FPGAs "the next = big thing in acceleration" -- Intel acquiring Altera and rumors of Xeons wi= th integrated FPGAs, IBM OpenPOWER systems with FPGA accelerators over CAPI= , Micron acquiring high-performance FPGA card makers Convey and Pico Comput= ing, and so on. As long as the ecosystem thrives and the tools improve, I'm= happy :) YamanArticle: 157984
This survey paper published in ACM Computing Surveys 2015 compares GPU with= FPGA and CPU on energy efficiency metric. Most papers reviewed in the surv= ey report that FPGA is more energy efficient than GPU, which, in turn, is m= ore energy efficient than CPU. =20 https://www.academia.edu/6644474/A_Survey_of_Methods_For_Analyzing_and_Impr= oving_GPU_Energy_EfficiencyArticle: 157985
On Thursday, June 4, 2015 at 11:16:36 PM UTC-4, rickman wrote:
> On 6/4/2015 10:20 PM, chrisabele wrote:
> > On 6/4/2015 5:15 PM, GaborSzakacs wrote:
> >> rickman wrote:
> >>> On 6/4/2015 11:45 AM, GaborSzakacs wrote:
> >>>> elraymonds wrote:
> >>>>> Did you mean timeline diagrams? You can use http://creately.com for
> >>>>> that. Its a online diagramming tool with real-time collaboration
> >>>>> enabled. try it
> >>>>>
> >>>>>
> >>>>
> >>>> Who? The person who posted the question 12 years ago?
> >>>
> >>> There was a guy writing a timing diagram editor some time back. I
> >>> think it was called timing designer or similar, but I see "timing
> >>> designer" is an expensive product name. I downloaded the early
> >>> versions and found it to be very lacking. I tried to give him
> >>> constructive feedback. After pushing it for two or three years he
> >>> seemed to stop posting about it.
> >>>
> >>> Is this what the original post was about?
> >>>
> >>
> >> Well the original post was looking for "any free software that draws
> >> timing diagrams." And the only reply at that time (12 years ago) was
> >> to check out the lite version of http://www.timingtool.com which
> >> still seems to exist.
> >>
> >> I do remember Timing Designer as being not very good, and eventually
> >> quite expensive. At the time I was using dV/dT on a Mac, which worked
> >> quite well for what it did. Nowadays I usually use a simulator to
> >> create timing diagrams more complex than any I might draw by hand.
> >>
> >
> > You guys are aware of the free TimingAnalyzer program for Windows,
> > right? If not, have a look at http://www.timing-diagrams.com.
> >
> > I'm no expert, but it looks like a big improvement over hand drawn
> > diagrams for just about any situation (and certainly would be easier to
> > revise).
>=20
> I think that is the one I saw some years ago. I think it was a labor of=
=20
> love for the author and he got little respect for it at the time. I'm=20
> glad to see that he stuck with it and turned it into something truly=20
> useful.
>=20
> --=20
>=20
> Rick
Hi Rick,
Wow! It has been a long time. I remember our converations about this a lon=
g time ago. I didn't realize how much work this was gone to be but I do en=
joy development and will probably always be working on some kind of CAD too=
l. I'm actually about 5 years away from retirement now and plan to do this =
CAD tool development full time then to keep busy.
=20
The TimingAnalyzer is alive and doing well. Progress is still very slow si=
nce it is a part time effort but that is nothing new and I have learned to =
accept that.
=20
I have focused most recently on timing analysis and added a timing engine t=
hat is accurate to the +-fS. There are ways to create timing diagrams from =
Verilog or VHDL or directly from VCD files and there are app notes describi=
ng how to do that with python scripts examples. The most recent app note, I=
ntro to Timing Analysis" includes real examples with python scripts to run =
them.
There are other programs out there you can use to draw timing diagrams so t=
he focus going forward will be on:
logic simulation with model delays
transaction based diagrams.
source code generation
python scripts for all operations
Keep in touch,
Dan Fabrizio
www.timing-diagrams.com
=20
=20
Article: 157986On Wed, 10 Jun 2015 12:40:41 -0700, computerarchitect wrote: > This survey paper published in ACM Computing Surveys 2015 compares GPU > with FPGA and CPU on energy efficiency metric. Most papers reviewed in > the survey report that FPGA is more energy efficient than GPU, which, in > turn, is more energy efficient than CPU. > > https://www.academia.edu/6644474/ A_Survey_of_Methods_For_Analyzing_and_Improving_GPU_Energy_Efficiency For one specific use, which is not the use that either GPUs or FPGAs were designed. (Of course, it is, theoretically, the use for which CPUs were designed, and that's the one that sucks the worst -- go figure). I did not read the paper. Did it say anything about the ease of programming for GPUs vs. FPGA in the applications they were looking at? In my (limited) experience with DSP vs. FPGA tradeoffs for video application, the ultimate performance limit was memory bandwidth -- did this paper address inter-processor communications and memory issues, or was it just doing some artificial test like Dhrystones or MFLOP/Joule or something? -- Tim Wescott Wescott Design Services http://www.wescottdesign.comArticle: 157987
I'd say your options are pretty limited. 1. Use a precompiler directive, which you can set when calling the synthesizer or simulator: test_module #(.FIFOBUF_WIDTH(WIDTH)) `DynamicInstanceName ( ... 2. Use a generate-case to select between a few instance name options based on a parameter. 3. Like the other respondent said, use Awk or TCL or some other scripting language to modify or write out HDL before running synth/sim. You could probably just put the name into an include file and then include that: test_module #(.FIFOBUF_WIDTH(WIDTH)) `inclue "Instancename.txt" ( ... These are all a bit kludgey. -KevinArticle: 157988
/sim. You could probably just put the name into an include file and then include that: > test_module #(.FIFOBUF_WIDTH(WIDTH)) > `inclue "Instancename.txt" > ( ... I meant "include". You can even use Verilog to generate Verilog. Pretty kludgey, but I've done that. You have to run the Verilog-generating Verilog first. Better to use some other language.Article: 157989
I don't know how much control you need, but I was thinking, for option #2, you could control at least the numeric index of the name, I think. For example: parameter K = 4; generate for (genvar j=K; j<=K; j=j+1) begin: gen_inst test_module #() SomeInstName (); end endgenerate In this case, I think your instance name would be something like gen_inst[4].SomeInstName, so you could at least change the index by changing K.Article: 157990
On Saturday, June 6, 2015 at 4:53:40 AM UTC-6, cpa...@yahoo.com wrote: > Hi, >=20 > I am trying create verilog module that can support parameterized instance= name. I understand that the signal width and other such things can be para= meterized. But can we also parameterize the module instance name? >=20 > In following code, I am curious if there is any way SomeDynamicInstanceNa= me can be parameterized also? I can try to use system verilog if that can h= elp here=20 >=20 > My purpose is to be able to reuse the verilog gmon module (generic verilo= g module) for various types of signals. But for a reason, I need to change= the SomeDynamicInstanceName. I have control of a verilog file where I ins= tantiate gmon verilog module so I can pass the parameters. >=20 > Prompt response is greatly appreciated. >=20 > `timescale 1 ns/100 ps >=20 >=20 > module gmon=20 > #( > parameter WIDTH =3D 32 > ) > (Clk, Rst, SignalName); >=20 >=20 > // PCIE MST_BIF > input Clk; > input Rst; > input [WIDTH-1:0] SignalName; >=20 > // input [31:0] SignalName_ret >=20 >=20 >=20 >=20 > reg [WIDTH-1:0] SignalName_d1; > //reg [31:0] SignalName_d2; >=20 >=20 >=20 >=20 > always @ (posedge Clk) begin > SignalName_d1 <=3D SignalName; > // SignalName_d2 <=3D SignalName_ret; > end >=20 >=20 > wire b =3D some combinatroial log; >=20 >=20 > test_module #(.FIFOBUF_WIDTH(WIDTH)) SomeDynamicInstanceName ( > .reset(Rst), //CHECK THIS -- ACTIVE HIGH > .wclk(Clk), > .out_data_valid(b), > .out_data(SignalName[WIDTH-1:0]), > .out_eom(1'b0), > .out_flush_file(1'b0), > .out_flush_pipe(1'b0) > ); Take a look at Verilog-mode (AUTO) for Emacs, if you use Emacs. You wont ge= t dynamic instance names with AUTO, but it is easy to do special things per= instance via AUTO_TEMPLATEs. Like if instance name is 'gmon0' connect bit = n to input y. If instance name is 'gmon1' then connect bit n+1 to input y e= tc. This could offer a new path to solve your issue.Article: 157991
Join UBM and Tech Online next week for a free webinar: =20 Overcome the challenges of powering FPGAs. =20 June 25th 11:00am PST/2:00pm EST An FPGA typically needs three or more voltage rails, each with a different = current requirement that depends upon the functionality being implemented i= n the design. This webinar will review the specifications that are needed t= o power FPGAs as well as suggest ways to overcome common challenges and pro= pose Xilinx=AE/Altera=AE solutions. Register today! https://webinar.techonline.com/19983?keycode=3DCOLWEBArticle: 157992
I have a small project that produces a clone of the "BABY" computer at MOSI. I want to be able to produce two versions of the code, one which displays on a VGA screen and another which uses a Luminescent display. To do this I need to be able to set different output signals depending on the way its built. At present I am building two different projects and keeping them both up to date is a bit of a pain. Dave WadeArticle: 157993
David Wade <dave.g4ugm@gmail.com> wrote: > I have a small project that produces a clone of the "BABY" computer at > MOSI. I want to be able to produce two versions of the code, one which > displays on a VGA screen and another which uses a Luminescent display. > To do this I need to be able to set different output signals depending > on the way its built. > At present I am building two different projects and keeping them both up > to date is a bit of a pain. For verilog, there is `ifdef, similar to the C #ifdef. It seems that VHDL has if/generate, but I haven't tried it. Otherwise, most synthesis tools are good at removing unused logic. If you code such that the unneeded signals aren't used, the logic to generate them won't be, either. But it looks to me like if/generate should do what you want. -- glen > Dave WadeArticle: 157994
glen herrmannsfeldt wrote: > David Wade <dave.g4ugm@gmail.com> wrote: >> I have a small project that produces a clone of the "BABY" computer at >> MOSI. I want to be able to produce two versions of the code, one which >> displays on a VGA screen and another which uses a Luminescent display. > >> To do this I need to be able to set different output signals depending >> on the way its built. > >> At present I am building two different projects and keeping them both up >> to date is a bit of a pain. > > For verilog, there is `ifdef, similar to the C #ifdef. > > It seems that VHDL has if/generate, but I haven't tried it. > > Otherwise, most synthesis tools are good at removing unused logic. > If you code such that the unneeded signals aren't used, the logic > to generate them won't be, either. > > But it looks to me like if/generate should do what you want. > > -- glen > >> Dave Wade I'm not sure if if/generate will help if what you want is to define a different set of module ports. `ifdef is pre-processed, so you can slap it anywhere in the code to conditionally include or leave out items. -- GaborArticle: 157995
In article <mm9ub8$qlq$1@dont-email.me>, GaborSzakacs <gabor@alacron.com> wrote: >glen herrmannsfeldt wrote: >> David Wade <dave.g4ugm@gmail.com> wrote: >>> I have a small project that produces a clone of the "BABY" computer at >>> MOSI. I want to be able to produce two versions of the code, one which >>> displays on a VGA screen and another which uses a Luminescent display. >> >>> To do this I need to be able to set different output signals depending >>> on the way its built. >> >>> At present I am building two different projects and keeping them both up >>> to date is a bit of a pain. >> >> For verilog, there is `ifdef, similar to the C #ifdef. >> >> It seems that VHDL has if/generate, but I haven't tried it. >> >> Otherwise, most synthesis tools are good at removing unused logic. >> If you code such that the unneeded signals aren't used, the logic >> to generate them won't be, either. >> >> But it looks to me like if/generate should do what you want. >> >> -- glen >> >>> Dave Wade > >I'm not sure if if/generate will help if what you want is to define a >different set of module ports. `ifdef is pre-processed, so you can slap >it anywhere in the code to conditionally include or leave out items. > >-- >Gabor Speaking VERY generally here, but I think it's appropriate... The usual way to solve this sort of thing is to group the requisite shared logic in shared files. Then have two unique top levels which just feed the approprate signals down to the shared modules. Pretty straightforward really; shared code lives in shared files. Unique code lives in unique files. If you find yourself cut/pasting code too much, you need to rethink the code organization. Also, do rely on synthesis optimizations, as Glen indicated. These tools are VERY mature, and very good at their job. If your shared code includes some redundant (or unused) information in a certain solution, that's ok - leave it dangling unused. The optimizer will remove the unusued logic just fine. Similarly for inputs to shared modules - tied constants at inputs are optimized just as easily (through sequential stages too). Regards, MarkArticle: 157996
Mark Curry <gtwrek@sonic.net> wrote: > In article <mm9ub8$qlq$1@dont-email.me>, (snip on optional logic for two choices) >>I'm not sure if if/generate will help if what you want is to define a >>different set of module ports. `ifdef is pre-processed, so you can slap >>it anywhere in the code to conditionally include or leave out items. Yes, it probably doesn't do that. I was thinking of the case where the ports have different signals for the two cases, or aren't used for one. > Speaking VERY generally here, but I think it's appropriate... > The usual way to solve this sort of thing is to group the requisite > shared logic in shared files. Then have two unique top levels > which just feed the approprate signals down to the shared > modules. That sounds about right to me, though it depends on the actual goal. With big FPGAs, it is almost as easy to generate logic and use only the parts you need. > Pretty straightforward really; shared code lives in shared files. > Unique code lives in unique files. If you find yourself > cut/pasting code too much, you need to rethink the code organization. > Also, do rely on synthesis optimizations, as Glen indicated. > These tools are VERY mature, and very good at their job. > If your shared code includes some redundant (or unused) > information in a certain solution, that's ok - leave it dangling > unused. The optimizer will remove the unusued logic just fine. I remember all those times where a tiny logic mistake causes the tools to remove everything. It takes some tracing back to see why it did that. > Similarly for inputs to shared modules - tied constants at inputs > are optimized just as easily (through sequential stages too). -- glenArticle: 157997
On 6/22/2015 2:33 PM, David Wade wrote: > I have a small project that produces a clone of the "BABY" computer at > MOSI. I want to be able to produce two versions of the code, one which > displays on a VGA screen and another which uses a Luminescent display. > > To do this I need to be able to set different output signals depending > on the way its built. > > At present I am building two different projects and keeping them both up > to date is a bit of a pain. I'm not sure you will find much difference keeping two projects up to date and keeping one project with two projects nested within "if" statements. I've tried this before and found it to be a royal PITA. The size of each file grows and the conditionals make the code much harder to read. What I ended up with was to encapsulate the two varieties in two separate files (rather than letting the differences be spread across the project) and built two separate projects. They were still 90+% the same so a lot of testing could be reused. -- RickArticle: 157998
Thanks for all the suggestions. More posts in-line,,,, On 22/06/2015 23:14, Mark Curry wrote: > In article <mm9ub8$qlq$1@dont-email.me>, > GaborSzakacs <gabor@alacron.com> wrote: >> glen herrmannsfeldt wrote: >>> David Wade <dave.g4ugm@gmail.com> wrote: >>>> I have a small project that produces a clone of the "BABY" computer at >>>> MOSI. I want to be able to produce two versions of the code, one which >>>> displays on a VGA screen and another which uses a Luminescent display. >>> >>>> To do this I need to be able to set different output signals depending >>>> on the way its built. >>> >>>> At present I am building two different projects and keeping them both up >>>> to date is a bit of a pain. >>> >>> For verilog, there is `ifdef, similar to the C #ifdef. >>> >>> It seems that VHDL has if/generate, but I haven't tried it. >>> >>> Otherwise, most synthesis tools are good at removing unused logic. >>> If you code such that the unneeded signals aren't used, the logic >>> to generate them won't be, either. >>> >>> But it looks to me like if/generate should do what you want. >>> >>> -- glen >>> >>>> Dave Wade >> >> I'm not sure if if/generate will help if what you want is to define a >> different set of module ports. `ifdef is pre-processed, so you can slap >> it anywhere in the code to conditionally include or leave out items. >> >> -- >> Gabor > > Speaking VERY generally here, but I think it's appropriate... > > The usual way to solve this sort of thing is to group the requisite > shared logic in shared files. Then have two unique top levels > which just feed the approprate signals down to the shared > modules. > > Pretty straightforward really; shared code lives in shared files. Unique code > lives in unique files. If you find yourself cut/pasting code too much, you > need to rethink the code organization. I think I need to do that any way, but I am finding it mildly challenging. I probably need to re-organize the code... > > Also, do rely on synthesis optimizations, as Glen indicated. These tools are > VERY mature, and very good at their job. If your shared code includes some > redundant (or unused) information in a certain solution, that's ok - leave it > dangling unused. The optimizer will remove the unusued logic just fine. > Similarly for inputs to shared modules - tied constants at inputs are optimized > just as easily (through sequential stages too). > OK I am sure I can do that but I. > Regards, > > Mark > DaveArticle: 157999
Mark Curry <gtwrek@sonic.net> wrote: > Also, do rely on synthesis optimizations, as Glen indicated. These tools are > VERY mature, and very good at their job. If your shared code includes some > redundant (or unused) information in a certain solution, that's ok - leave it > dangling unused. The optimizer will remove the unusued logic just fine. Except when it doesn't. For instance, I have a toplevel model that defines some ports that are driven by transceivers. The pins are configured with appropriate I/O standards etc in the project configuration. Let's say I change my PCIe port from 4x to 1x, which is a simple dropdown on the PCIe core. If I have the ports on my toplevel module, but don't connect them to anything, I get an error. If I remove the ports from my toplevel module, but leave the transceiver settings alone, it compiles. The result is I have to do: module toplevel ( output PCIE_TX0_p, input PCIE_RX0_p, `ifdef PCIE_LANES_2X output PCIE_TX1_p, input PCIE_RX1_p, `ifdef PCIE_LANES_4X output PCIE_TX2_p, input PCIE_RX2_p, ... `endif `endif ) This is an unusual corner case, but there's an unusual case around every corner. Theo
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