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 27/10/2018 13:12, Theo wrote: .. >> www.synthworks.com/papers/VHDL_2008_end_of_verbosity_2013.pdf >> >> Personally I think verbosity is a good thing as it makes it easier to >> understand somebody else's code. I should have said "verbosity to a certain degree", of course you can have too much verbosity which can lead to bugs (TLDR phenomenon). There are occasions where you want to have concise code. In my C code I do use the '?' operator quite a bit. > > I'm don't have much to do with VHDL, but that sounds like it's making a bad > thing slightly less bad. I'd be interested if you could point me towards an > example of tight VHDL? > I cannot answer this as it is too broad. > The other issue that that a lot of these updated VHDL and Verilog standards > take a long time to make it into the tools. So if you code in a style > that's above the lowest common denominator, you're now held hostage about > using the particular tool that supports your chosen constructs. <rant> Tell me about it, I am currently wasting time removing VHDL2008 constructs as Quartus Pro supports VHDL2008 but Quartus Prime does not. Why does Intel think it is a good approach to have 2 fully supported P&R products with different language support? Customers using a Cyclone10GX cannot easily move to Cyclone10LP without mutilating their VHDL. </rant> But to answer your question, I think you just shot yourself in the foot as BlueSpec BSV is a worse hostage taker than a standardised VHDL2008/SV language. As far as I can tell Bluespec BSV is not an open standard and there is no second source so any company using BSV is locked into the Bluespec's toolchain. At least with VHDL2008/SV I can move to many other vendors. I haven't spend much time looking into Bluespec but I do know that many companies are nervous adopting a custom language supported by a single vendor. > > There's another type of tool out there, that compiles to Verilog as its > 'assembly language'. Basic register-transfer Verilog is pretty universally > supported, and so they support most toolchains. > > As regards FIFOs, here's a noddy example: > > > import FIFO::*; > > interface Pipe_ifc; > method Action send(Int#(32) a); > method ActionValue#(Int#(32)) receive(); > endinterface > > module mkDoubler(Pipe_ifc); > FIFO#(Int#(32)) firstfifo <- mkFIFO; > FIFO#(Int#(32)) secondfifo <- mkFIFO; > > rule dothedoubling; > let in = firstfifo.first(); > firstfifo.deq; > secondfifo.enq ( in * 2 ); > endrule > > method Action send(Int#(32) a); > firstfifo.enq(a); > endmethod > > method ActionValue#(Int#(32)) receive(); > let result = secondfifo.first(); > secondfifo.deq; > return result; > endmethod > > endmodule > > > This creates a module containing two FIFOs, with a standard pipe interface - > a port for sending it 32 bit ints, and another for receiving 32 bit ints > back from it. Inside, one FIFO is wired to the input of the module, the > other to the output. When data comes in, it's stored in the first FIFO. > When there is space in the second FIFO, it's dequeued from the first, > doubled, and enqueued in the second. If any FIFO becomes full, backpressure > is automatically applied. There's no chance of data getting lost by missing > control signals. > Impressive example, however, I am not sure if any other high level RTL language will be a lot more verbose. You are instantiating a FIFO and connecting the ports with a bit of control logic right? > This is Bluespec's BSV, not VHDL or Verilog. The compiler type checked it > for me, so I'm very confident it will work first time. I could have made it > polymorphic (there's nothing special about 32 bit ints here) with only a > tiny bit more work. It compiles to Verilog which I can then synthesise. > > Notice there are no clocks or resets (they're implicit unless you say you > want multiple clock domains), no 'if valid is high then' logic, it's all > taken care of. This means you can write code that does a lot of work very > concisely. It looks like BSV sits between RTL and HLS, you have raised the level of abstraction but still have an implicit clock. Thanks for the example, Hans www.ht-lab.com > > Theo >Article: 160726
> And that is exactly my point. The problem you point out is not a problem= related in any way to implementing in FPGAs, it's that the design is inher= ently complex. While you may be able to define the design in an abstract w= ay in Matlab, that is not the same thing as an implementation in *any* medi= um or target.=20 >=20 > Your claim was, "the whole FPGA market is limited because any real work m= ust be done by experiences specialists working at a very low level of abstr= action". This isn't a problem with the FPGA aspect, it is a problem with t= he task being implemented since it would be the same problem with any targe= t. =20 It's hard to turn abstract sequential code into a parallelized algorithm. = But a more basic issue is the poor tools and lack of IP that requires low-l= evel coding for everything, almost as if a C coder had to write his own pri= ntf() function. If you just want to implement an algorithm and speed and g= ates are not an issue, then yes, things are easy. But we rarely get projec= ts like that, because those are done in microcontrollers. > I'm not sure how you can do that in any language unless fifo.push_front()= is already defined. Are you suggesting it be a part of a language? In C = there are many libraries for various commonly used functions. In VHDL ther= e are some libraries for commonly used, but low level functions, nothing li= ke a fifo. If you write a procedure to define fifo.push_front() you can do= exactly this, but there is none written for you. =20 >=20 That is actual syntax from Systemverilog. When I want to set up a FIFO in = a testbench, I declare a queue and use the .push_front() and .pop_back() me= thods. It's already in the language; it just isn't supported in synthesis.= This isn't a case where I'm asking the tool to convert sequential to para= llel; I'm just asking it to look for a function call and instantiate a FIFO= . Just something to make the code a little easier to write, read, and main= tain.Article: 160727
> The other issue that that a lot of these updated VHDL and Verilog standar= ds > take a long time to make it into the tools. So if you code in a style > that's above the lowest common denominator, you're now held hostage about > using the particular tool that supports your chosen constructs. This is the problem I run into all the time. No matter how low-level I wri= te something, some tool somewhere won't like it and I have to write it in a= yet lower level. It's amazing how many tools can't parse basic things fro= m Verilog-2005. It's been thirteen years! I ran into some tool recently, = maybe it was Synopsys DC, which doesn't allow $readmemh(), which I think mi= ght from Verilog-1995, and which I've been using my whole career. I had to= rewrite a bunch of code as a result. So much time spent rewriting stuff t= hat already works.Article: 160728
> I am, I am just surprised that you have so a low appreciation of the > current technology. > > HLS is happening but it will be a many decades before our skill set > becomes obsolete (assuming we don't keep up). > I've been fooled too many times before. I'm not going to be a chump and waste any more time it.Article: 160729
On Saturday, October 27, 2018 at 5:36:40 AM UTC-4, HT-Lab wrote: > On 27/10/2018 07:22, gnuarm.deletethisbit@gmail.com wrote: > > On Saturday, October 27, 2018 at 12:30:55 AM UTC-4, Kevin Neilson wrote= : > .. > >> It's not necessarily that it's in Matlab that makes it easy, but that = it's very abstracted. It might not be that much harder in abstract SystemV= erilog. What takes months is converting to a parallelized design, adding p= ipelining, meeting timing, placing, dealing with domain crossings, instanti= ating primitives when necessary, debugging, etc. The same would be true of= any language. I suppose you can get an FPGA written in C to work as well,= but it's not going to be *abstract* C. It's going to be the kind of C tha= t looks like assembly, in which the actual algorithm is indiscernible witho= ut extensive comments. > >=20 > > And that is exactly my point. The problem you point out is not a probl= em related in any way to implementing in FPGAs, it's that the design is inh= erently complex. While you may be able to define the design in an abstract= way in Matlab, that is not the same thing as an implementation in *any* me= dium or target. > >=20 > > Your claim was, "the whole FPGA market is limited because any real work= must be done by experiences specialists working at a very low level of abs= traction". This isn't a problem with the FPGA aspect, it is a problem with= the task being implemented since it would be the same problem with any tar= get. > >=20 >=20 > Well said. >=20 > .. > >>> > >>> I don't know, why can't *you* infer a fifo? The code required is not= complex. Are you saying you feel you have to instantiate a vendor module = for that??? I recall app notes from some time ago that explained how to us= e gray counters to easily infer fifos. Typically the thing that slows me d= own in HDL is the fact that I'm using VHDL with all it's verbosity. =20 >=20 > really, what aspect of VHDL is slowing you down that would be quicker in= =20 > Verilog? >=20 > www.synthworks.com/papers/VHDL_2008_end_of_verbosity_2013.pdf That's a great paper for a newbie to learn some advantages of VHDL-2008, bu= t it is far from justifying that VHDL isn't verbose. =20 One of the most verbose aspects of VHDL is the need to type signals three t= imes when instantiating modules. 1) typing the module, 2) typing the insta= nce, 3) typing the signal declarations in the module where the instance is = used. I had regular expressions I used to convert between these forms. I = expect some editors do this for you. I think VHDL-2008 provides a way to a= void typing the ports in instantiations (or the whole instantiation), but I= don't recall the details and I don't see it in the above paper. =20 > Personally I think verbosity is a good thing as it makes it easier to=20 > understand somebody else's code. Sure, that's no small reason why I haven't switched. The guys who's Verilo= g code I see seem to eschew white space and cram it all together. I find t= hat alone to make the code hard to read. But it's all about what you are u= sed to really. They seem to get along just fine.=20 > >Some tools help with that, but I don't have those. I've just never bitt= en the bullet to try working much in Verilog. >=20 > I would forget about Verilog as it has too many quirks, go straight to=20 > SystemVerilog (or just stick with VHDL). I'm not doing much with any HDL so little chance of working with anything o= ther than VHDL at the moment.=20 These days I mostly receive POs and issue POs.=20 RickArticle: 160730
On Saturday, October 27, 2018 at 8:12:05 AM UTC-4, Theo wrote: > HT-Lab <hans64@htminuslab.com> wrote: > > On 27/10/2018 07:22, gnuarm.deletethisbit@gmail.com wrote: > > > On Saturday, October 27, 2018 at 12:30:55 AM UTC-4, Kevin Neilson wro= te: >=20 > > >>> I don't know, why can't *you* infer a fifo? The code required is n= ot > > >>> complex. Are you saying you feel you have to instantiate a vendor > > >>> module for that??? I recall app notes from some time ago that > > >>> explained how to use gray counters to easily infer fifos. Typicall= y > > >>> the thing that slows me down in HDL is the fact that I'm using VHDL > > >>> with all it's verbosity. > >=20 > > really, what aspect of VHDL is slowing you down that would be quicker i= n=20 > > Verilog? > >=20 > > www.synthworks.com/papers/VHDL_2008_end_of_verbosity_2013.pdf > >=20 > > Personally I think verbosity is a good thing as it makes it easier to= =20 > > understand somebody else's code. >=20 > I'm don't have much to do with VHDL, but that sounds like it's making a b= ad > thing slightly less bad. I'd be interested if you could point me towards= an > example of tight VHDL? I don't think that is the point. The verbosity of VHDL is intended. There= are things that you have to do in VHDL that aren't done in Verilog where t= he intent is to avoid a class of mistakes. This is the reason for strong t= yping which brings on some verbosity. =20 an_integer_variable <=3D to_integer(some_other_data_type);=20 Sometimes the function to_integer() isn't defined for that "other" data typ= e and you have to write the conversion function or convert to an intermedia= te type. The point is to not *assume* the compiler knows what the user int= ended and to make it all explicit. Then a subsequent reader can see exactl= y what was intended. =20 In the same vein I usually use explicit parentheses rather than letting my = expression default to standard order of operations. I think it is more cle= ar to be explicit.=20 > The other issue that that a lot of these updated VHDL and Verilog standar= ds > take a long time to make it into the tools. So if you code in a style > that's above the lowest common denominator, you're now held hostage about > using the particular tool that supports your chosen constructs. It's not quite that bad. The tools support what the users request. So the= most often used features are supported in most tools. =20 > This is Bluespec's BSV, not VHDL or Verilog. The compiler type checked i= t > for me, so I'm very confident it will work first time. I could have made= it > polymorphic (there's nothing special about 32 bit ints here) with only a > tiny bit more work. It compiles to Verilog which I can then synthesise. What about simulation? Is the BSV simulated or the Verilog?=20 > Notice there are no clocks or resets (they're implicit unless you say you > want multiple clock domains), no 'if valid is high then' logic, it's all > taken care of. This means you can write code that does a lot of work ver= y > concisely. How do you distinguish code that is combinatorial?=20 Rick C.Article: 160731
On Saturday, October 27, 2018 at 9:52:13 AM UTC-4, Michael Kellett wrote: > =20 > Lattice have some ice40 series parts in 48pin 0.5mm pitch QFN, easily=20 > hotplate and hand solderable. I've probably seen these and forgotten them since they are a bit too small = for my needs. I'm using an obsolete Lattice XP part in a 100 pin TQFP with= 60+ I/Os. The 48QFN is very interesting, but won't actually fit my need. = Thanks for the reminder though. Maybe two of them, lol > Altera have MAX10 with 50kLUTs (approx) in 144 pin TQFP. Yeah, not so small though. The package is 22 mm square and my board is onl= y 21.6 mm wide! If I have to I can squeeze a BGA-256 on the board. I just= don't want to deal with the layout issues.=20 > There are no modern Xilinx parts in other than BGA but you can get Artix= =20 > and Spartan 7 in 1mm pitch BGA. Should be possible to use on low cost=20 > (0.15mm track and gap) 4 layer boards. > I mean to try quite soon - I'll let you know. That might work. I haven't looked at replacements in awhile. Didn't even = know of the 196 pin package. Thanks. For the time being I can get all the= XP parts I need. Rick C.Article: 160732
HT-Lab <hans64@htminuslab.com> wrote: > <rant> > Tell me about it, I am currently wasting time removing VHDL2008 > constructs as Quartus Pro supports VHDL2008 but Quartus Prime does not. > Why does Intel think it is a good approach to have 2 fully supported P&R > products with different language support? Customers using a Cyclone10GX > cannot easily move to Cyclone10LP without mutilating their VHDL. > </rant> Oh, I hadn't realised that - that's a pain. > But to answer your question, I think you just shot yourself in the foot > as BlueSpec BSV is a worse hostage taker than a standardised VHDL2008/SV > language. As far as I can tell Bluespec BSV is not an open standard and > there is no second source so any company using BSV is locked into the > Bluespec's toolchain. At least with VHDL2008/SV I can move to many other > vendors. > > I haven't spend much time looking into Bluespec but I do know that many > companies are nervous adopting a custom language supported by a single > vendor. Yes, this is a big problem. It's something Bluespec Inc themselves realise too - I think they would open source the compiler but they have customers who are paying the bills, so... (There are also other toy BSV compilers around, but nothing I've seen that's production ready) However it's slightly different from the VHDL/Verilog problem. The VHDL/Verilog tools are compiling to something else (standard cells, FPGA netlists). If you're targeting Altera, you have to use Quartus for this. If you want to move your code to an ASIC, you now have to switch to Synopsys DC (or whatever), and discover that your SystemVerilog constructs aren't supported. In the BSV case, the Verilog 95 emitted by the BSV compiler can be used with Altera or Synopsys. So your backend is flexible, even if one piece of your frontend is fixed. > Impressive example, however, I am not sure if any other high level RTL > language will be a lot more verbose. You are instantiating a FIFO and > connecting the ports with a bit of control logic right? In that noddy example. Interfaces mean you can wrap up a lot of verbosity into a few lines. For a randomly selected example, here's a processor TLB, in 500 lines of BSV: https://github.com/CTSRD-CHERI/beri/blob/master/cheri/trunk/TLB.bsv Also, being polymorphic, you can generate a variety of different modules from the one description - which saves a lot of repetition. > It looks like BSV sits between RTL and HLS, you have raised the level of > abstraction but still have an implicit clock. Yes. It's still timed, so you still have decide what's going in each cycle. (or at least your idea of that - your synthesis tool may retime). And it's possible to get bubbles - your system still works, but takes more cycles because parts will stall if there's no data for them to operate on. Also, there's still skill in understanding what will impact your critical path. ISTM one issue with HLS is it's good at handling work in the datapath, but perhaps not so good in the control path. So you can describe some kinds of compute very well, but I'm not sure how well they would handle a control-heavy structure like a cache. TheoArticle: 160733
On Saturday, October 27, 2018 at 4:14:59 PM UTC-4, Kevin Neilson wrote: > > And that is exactly my point. The problem you point out is not a probl= em related in any way to implementing in FPGAs, it's that the design is inh= erently complex. While you may be able to define the design in an abstract= way in Matlab, that is not the same thing as an implementation in *any* me= dium or target.=20 > >=20 > > Your claim was, "the whole FPGA market is limited because any real work= must be done by experiences specialists working at a very low level of abs= traction". This isn't a problem with the FPGA aspect, it is a problem with= the task being implemented since it would be the same problem with any tar= get. =20 >=20 > It's hard to turn abstract sequential code into a parallelized algorithm.= But a more basic issue is the poor tools and lack of IP that requires low= -level coding for everything, almost as if a C coder had to write his own p= rintf() function. If you just want to implement an algorithm and speed and= gates are not an issue, then yes, things are easy. But we rarely get proj= ects like that, because those are done in microcontrollers. I don't agree with that last bit. The difference in speed and density of a= design is orders of magnitude between FPGAs and MCUs. There is plenty of = room for easier FPGA designs that still won't be easy even if possible on a= n MCU.=20 > > I'm not sure how you can do that in any language unless fifo.push_front= () is already defined. Are you suggesting it be a part of a language? In = C there are many libraries for various commonly used functions. In VHDL th= ere are some libraries for commonly used, but low level functions, nothing = like a fifo. If you write a procedure to define fifo.push_front() you can = do exactly this, but there is none written for you. =20 > >=20 > That is actual syntax from Systemverilog. When I want to set up a FIFO i= n a testbench, I declare a queue and use the .push_front() and .pop_back() = methods. It's already in the language; it just isn't supported in synthesi= s. This isn't a case where I'm asking the tool to convert sequential to pa= rallel; I'm just asking it to look for a function call and instantiate a FI= FO. Just something to make the code a little easier to write, read, and ma= intain. But if it isn't supported in synthesis, what good is it? If I am coding fo= r simulation only I can take all manner of shortcuts.=20 Rick C.Article: 160734
gnuarm.deletethisbit@gmail.com wrote:
> I don't think that is the point. The verbosity of VHDL is intended.
> There are things that you have to do in VHDL that aren't done in Verilog
> where the intent is to avoid a class of mistakes. This is the reason for
> strong typing which brings on some verbosity.
Types are good. But why do I have to write
'signal x : std_logic_vector(31 downto 0)' when I could just type
'logic [31:0] x' ?
> an_integer_variable <= to_integer(some_other_data_type);
>
> Sometimes the function to_integer() isn't defined for that "other" data
> type and you have to write the conversion function or convert to an
> intermediate type. The point is to not *assume* the compiler knows what
> the user intended and to make it all explicit. Then a subsequent reader
> can see exactly what was intended.
I agree completely. But you can be explicit without hurting your keyboard.
Spend the keystrokes where it matters.
(I'm fed up of reading through pages and pages of Verilog code that merely
describes the interfaces to a component, which does a tiny amount of work and
then instantiates another component that's almost the same inside it. When
you get 8 levels down in this tree of input and output wires it gets very
tiresome)
> It's not quite that bad. The tools support what the users request. So
> the most often used features are supported in most tools.
So why is there a standard if tools can cherry pick what is and isn't
supported? One of my colleagues has a table of what SystemVerilog features
are supported across different tools. To have a multi-tool project, you end
up with the lowest common denominator, at which point most of the useful
features aren't an option.
> What about simulation? Is the BSV simulated or the Verilog?
BSV has its own simulator, which simulates at a higher level of abstraction
so runs a lot faster than a Verilog simulator. You can, of course, simulate
the verilog if you want to, but generally we find that code that simulates
in the BSV simulator will work first time on FPGA.
(The tricky bit is dealing with external IP like DRAMs - to get better
testing coverage we have randomised models in BSV, rather than simulating
the DRAM controller and DRAM IP in Modelsim)
> How do you distinguish code that is combinatorial?
function Bool i2xj( td i, td j )
provisos( Arith#(td), Eq#(td) );
return ( (i - 2*j) == 0 );
endfunction
is a polymorphic combinatorial function that takes two inputs i and j. We
don't know the type of i and j, but we do know that it must be the same, the
type (we'll call it 'td') must support arithmetic and testing equality. If
it doesn't, it's a compile error. So I couldn't use this for a string, for
example.
For any instantiation of this function, we'll accept the parameters i and j
and generate logic that computes i-2j and compares it to zero, returning a
boolean value.
If I wanted to instantiate this in a module, I'd do something like:
// define some registers with their types and default values
Reg#(UInt#(64)) f <- mkReg(44);
Reg#(UInt#(64)) g <- mkReg(22);
Reg#(Int#(9)) p <- mkReg(-1);
Reg#(Int#(9)) q <- mkReg(4);
Reg#(Bool) m <- mkReg(False);
Reg#(Bool) n <- mkReg(True);
rule comparethem;
// at the next clock cycle, set h to the combinatorial function of f and g
m <= i2xj(f, g);
// instantiate another copy of the function, this time with
// different types
n <= i2xj(p, q);
endrule
If you want your module to have purely combinational behaviour, there are
'Wire' types which act like registers but return the answer in the current
clock cycle, not the next one (unlike Verilog, a Wire has the same syntax as
a Reg, but different timing behaviour).
The compiler will schedule logic so that things that depend on Wire outputs
are downstream so that they are consumed when the wires have computed their
results. Wires are commonly used to pass data between rules (which are the
building block of BSV, each one being an atomic action with implicit
conditions).
Theo
Article: 160735gnuarm.deletethisbit@gmail.com wrote: > Yeah, not so small though. The package is 22 mm square and my board is > only 21.6 mm wide! If I have to I can squeeze a BGA-256 on the board. I > just don't want to deal with the layout issues. If it's an FPGA, I think you can get quite a way by just ignoring half of the balls. Provide power and ground, then just use the I/Os that are easy to get at and ground the rest. Depends what you need in terms of pins, but it makes the BGA escapes a lot easier if you only have to go a couple of rows deep. Obviously this doesn't work for chips where balls have a fixed function! TheoArticle: 160736
On Saturday, October 27, 2018 at 6:41:44 PM UTC-4, Theo wrote: > gnuarm.deletethisbit@gmail.com wrote: > > I don't think that is the point. The verbosity of VHDL is intended. > > There are things that you have to do in VHDL that aren't done in Verilog > > where the intent is to avoid a class of mistakes. This is the reason for > > strong typing which brings on some verbosity. > > Types are good. But why do I have to write > 'signal x : std_logic_vector(31 downto 0)' when I could just type > 'logic [31:0] x' ? I see you are not very familiar with VHDL strong typing. In your example, what type is x? What sort of values can be assigned to it? What type of math is used when it is added to the same type? > > an_integer_variable <= to_integer(some_other_data_type); > > > > Sometimes the function to_integer() isn't defined for that "other" data > > type and you have to write the conversion function or convert to an > > intermediate type. The point is to not *assume* the compiler knows what > > the user intended and to make it all explicit. Then a subsequent reader > > can see exactly what was intended. > > I agree completely. But you can be explicit without hurting your keyboard. > Spend the keystrokes where it matters. > > (I'm fed up of reading through pages and pages of Verilog code that merely > describes the interfaces to a component, which does a tiny amount of work and > then instantiates another component that's almost the same inside it. When > you get 8 levels down in this tree of input and output wires it gets very > tiresome) > > > It's not quite that bad. The tools support what the users request. So > > the most often used features are supported in most tools. > > So why is there a standard if tools can cherry pick what is and isn't > supported? One of my colleagues has a table of what SystemVerilog features > are supported across different tools. To have a multi-tool project, you end > up with the lowest common denominator, at which point most of the useful > features aren't an option. Yep. Vendors give users what they ask for. If you are a paying customer you should inquire about any feature you feel should be included. If you aren't a paying customer, I guess you have no say. > > What about simulation? Is the BSV simulated or the Verilog? > > BSV has its own simulator, which simulates at a higher level of abstraction > so runs a lot faster than a Verilog simulator. You can, of course, simulate > the verilog if you want to, but generally we find that code that simulates > in the BSV simulator will work first time on FPGA. I guess you are stuck with the one vendor then, although I shouldn't use a loaded word like "stuck". Rick C.Article: 160737
On Saturday, October 27, 2018 at 7:02:56 PM UTC-4, Theo wrote: > gnuarm.deletethisbit@gmail.com wrote: > > Yeah, not so small though. The package is 22 mm square and my board is > > only 21.6 mm wide! If I have to I can squeeze a BGA-256 on the board. = I > > just don't want to deal with the layout issues. >=20 > If it's an FPGA, I think you can get quite a way by just ignoring half of > the balls. Provide power and ground, then just use the I/Os that are eas= y to > get at and ground the rest. >=20 > Depends what you need in terms of pins, but it makes the BGA escapes a lo= t > easier if you only have to go a couple of rows deep. >=20 > Obviously this doesn't work for chips where balls have a fixed function! You mean like power and ground? I recall one type of BGA that has concentr= ic rings of I/Os with a large open area in the center. Easy to route but I= don't see those anymore. It is common to put power and ground near the ce= nter as it results in shorter, lower inductance paths inside the chip packa= ge. So those pretty much always need vias between the pads.=20 Rick C.Article: 160738
gnuarm.deletethisbit@gmail.com wrote: > On Saturday, October 27, 2018 at 6:41:44 PM UTC-4, Theo wrote: > > Types are good. But why do I have to write > > 'signal x : std_logic_vector(31 downto 0)' when I could just type > > 'logic [31:0] x' ? > > I see you are not very familiar with VHDL strong typing. > > In your example, what type is x? What sort of values can be assigned to > it? What type of math is used when it is added to the same type? So if I was writing in a strongly typed language rather than a disaster like Verilog, it would be: Reg#(UInt#(32)) - still a lot fewer keystrokes. UInt supports Bits (can be converter to a bit vector), Eq (can be equality tested), Arith (arithmetic operations), and so on. The behaviour when combining two values of the same or different types are defined, and I can overload them if I really want to (but I probably don't). TheoArticle: 160739
On Sunday, October 28, 2018 at 7:51:11 AM UTC-4, Theo wrote: > gnuarm.deletethisbit@gmail.com wrote: > > On Saturday, October 27, 2018 at 6:41:44 PM UTC-4, Theo wrote: > > > Types are good. But why do I have to write > > > 'signal x : std_logic_vector(31 downto 0)' when I could just type > > > 'logic [31:0] x' ? > > > > I see you are not very familiar with VHDL strong typing. > > > > In your example, what type is x? What sort of values can be assigned to > > it? What type of math is used when it is added to the same type? > > So if I was writing in a strongly typed language rather than a disaster like > Verilog, it would be: > > Reg#(UInt#(32)) > > - still a lot fewer keystrokes. > > UInt supports Bits (can be converter to a bit vector), Eq (can be equality > tested), Arith (arithmetic operations), and so on. The behaviour when > combining two values of the same or different types are defined, and I can > overload them if I really want to (but I probably don't). I'm still not clear on the syntax. Is Reg the signal name? What types are there other than UInt which I assume is an unsigned integer? Verilog has always confused me with reg and wire (I think). I've never understood what the difference was. That's mostly because I've never bought a good book on it and that's because every time I ask I'm told there are *no* good books, lol. Rick C.Article: 160740
On 27/10/2018 22:57, Theo wrote: > HT-Lab <hans64@htminuslab.com> wrote: .. >> I haven't spend much time looking into Bluespec but I do know that many >> companies are nervous adopting a custom language supported by a single >> vendor. > > Yes, this is a big problem. It's something Bluespec Inc themselves realise > too - I think they would open source the compiler but they have customers > who are paying the bills, so... > > (There are also other toy BSV compilers around, but nothing I've seen that's > production ready) At least there is enough information available in the public domain to write a toy BSV compiler, that is good news (patents issues aside). I assume Bluespec has a healthy customer list so assuming they sell perpetual licenses I guess the plunge is not that big. > > However it's slightly different from the VHDL/Verilog problem. The > VHDL/Verilog tools are compiling to something else (standard cells, FPGA > netlists). If you're targeting Altera, you have to use Quartus for this. If > you want to move your code to an ASIC, you now have to switch to Synopsys DC > (or whatever), and discover that your SystemVerilog constructs aren't > supported. In the BSV case, the Verilog 95 emitted by the BSV compiler can > be used with Altera or Synopsys. So your backend is flexible, even > if one piece of your frontend is fixed. OK, I will give you that one. As we all know switching between vendors always requires work. > >> Impressive example, however, I am not sure if any other high level RTL >> language will be a lot more verbose. You are instantiating a FIFO and >> connecting the ports with a bit of control logic right? > > In that noddy example. Interfaces mean you can wrap up a lot of verbosity > into a few lines. For a randomly selected example, here's a processor TLB, > in 500 lines of BSV: > https://github.com/CTSRD-CHERI/beri/blob/master/cheri/trunk/TLB.bsv > The code looks very tidy but of course I can't compare it to any other implementation. I have written my own TLB (for a 486) and it is about 900 lines of VHDL but again no way to compare them. From your examples I can see BSV is a lot more verbose and expressive at the same time, I guess that is the advantage of a modern language well though out language. > Also, being polymorphic, you can generate a variety of different modules from > the one description - which saves a lot of repetition. > >> It looks like BSV sits between RTL and HLS, you have raised the level of >> abstraction but still have an implicit clock. > > Yes. It's still timed, so you still have decide what's going in each cycle. > (or at least your idea of that - your synthesis tool may retime). And it's > possible to get bubbles - your system still works, but takes more cycles > because parts will stall if there's no data for them to operate on. That is interesting as we are no longer talking about a more modern expressive language which has a user understandable mapping to hardware but actually something that implements flow control as well. This is quite nice but a bit worrying as it makes the debugging from your Verilog95 back to BSV a lot more complex. This is one aspect that is always playing in the HLS world, how do you guarantee your untimed C/C++ code is equivalent to the produced RTL. Calypto can do this but I am sure this is outside the EDA budget for most of us. If I find a critical path during synthesis, how easy is this to link back to the BSV code? > Also, there's still skill in understanding what will impact your critical > path. > > ISTM one issue with HLS is it's good at handling work in the datapath, but > perhaps not so good in the control path. So you can describe some kinds of > compute very well, but I'm not sure how well they would handle a > control-heavy structure like a cache. You are absolutely right, for the control logic they always suggest to either use one of the RTL languages or SystemC (which has similar constructs to VHDL/Verilog). Thanks for the BSV examples, quite interesting. Hans www.ht-lab.com > > Theo >Article: 160741
gnuarm.deletethisbit@gmail.com wrote: > On Sunday, October 28, 2018 at 7:51:11 AM UTC-4, Theo wrote: > > So if I was writing in a strongly typed language rather than a disaster > > like Verilog, it would be: > > > > Reg#(UInt#(32)) > > > > - still a lot fewer keystrokes. > > > > UInt supports Bits (can be converter to a bit vector), Eq (can be equality > > tested), Arith (arithmetic operations), and so on. The behaviour when > > combining two values of the same or different types are defined, and I can > > overload them if I really want to (but I probably don't). > > I'm still not clear on the syntax. Is Reg the signal name? What types > are there other than UInt which I assume is an unsigned integer? Reg is the typeclass of the hardware being built, which is parameterised (# symbol) on type UInt (unsigned int), which is itself parameterised with the number 32. In other words, we're defining a register (a general purpose thing that can hold a variety of things) specifically to hold UInts, and those UInts happen to be 32 bits long. Other basic types are Bits (a pile of bits), Int (signed integers that can be converted to piles of bits), Bool (boolean - True or False), Integer (integers that aren't bits, often used for polymorphism - the '32' in the above is an Integer), Real numbers (without a direct representation as bits - if you want that you have to write conversion functions), Strings, and so on. There are also things like Maybe types, which can either hold a value (of a type you specify) or Invalid (meaning this container does not hold a value). There's nothing special about any of these typeclasses - you can build your own if you want. If you're instantiating a register you need to give it an implementation, so a register called 'bob' would be: Reg#(UInt#(32)) bob <- mkReg(99); 'mkReg' is a particular implementation of the Reg typeclass (there are others), and 99 is a parameter to mkReg (in this case, the value on reset). > Verilog has always confused me with reg and wire (I think). I've never > understood what the difference was. That's mostly because I've never > bought a good book on it and that's because every time I ask I'm told > there are *no* good books, lol. In Verilog, AIUI there is no difference - that's why SystemVerilog has 'logic' to avoid people thinking there is. It purely depends on how they get used, which makes more sense when you consider Verilog's origins as an event simulation language. The difference between: always @(posedge s or negedge s) a <= s+2; assign a = s+2; is that the 'always @(posedge s or negedge s)' will update a on 'any edge of s' [1], and 'assign' will update a on of 'any edge of s and the start of the simulation'. The latter boils down to a combinational function, the former is a stateful element - holding a value until the first edge of 's', or some other condition like @(posedge clock). Once you stop thinking about digital logic and think about arbitrary events it makes more sense. Theo [1] technically, to write that would need always @(s) because there are other kinds of edges beyond posedge or negedge, like edges to Z, X, etc. @(s) means 'any transition on signal s'.Article: 160742
On 28/10/2018 13:00, gnuarm.deletethisbit@gmail.com wrote: > On Sunday, October 28, 2018 at 7:51:11 AM UTC-4, Theo wrote: .. > > I'm still not clear on the syntax. Is Reg the signal name? What types are there other than UInt which I assume is an unsigned integer? > > Verilog has always confused me with reg and wire (I think). I've never understood what the difference was. SystemVerilog cleaned up the language significantly, instead of reg and wire you can now use the logic type. Unfortunately SystemVerilog is build on top of (the in 1984 developed) Verilog so you still have to deal with all the blocking and non-blocking nonsense. SystemC and VHDL users are lucky in that they only have to deal with the odd delta cycle issue. I guess there are no delta cycle issues in BSV. > That's mostly because I've never bought a good book on it and that's because every time I ask I'm told there are *no* good books, lol. My company send me on a Doulos Verilog course many years ago. Doulos courses are not cheap but they are very very good. But even with a good course you still have to practice, practice and when you have a spare second practise. If you leave the language for a few years you have to start from scratch again unless you are below 30. Given that most simulators are now dual language you can write small blocks in SV and use that with your VHDL code. I did the same for SystemC. Hans www.ht-lab.com > > Rick C. >Article: 160743
HT-Lab <hans64@htminuslab.com> wrote: > On 27/10/2018 22:57, Theo wrote: > That is interesting as we are no longer talking about a more modern > expressive language which has a user understandable mapping to hardware > but actually something that implements flow control as well. This is > quite nice but a bit worrying as it makes the debugging from your > Verilog95 back to BSV a lot more complex. This is one aspect that is > always playing in the HLS world, how do you guarantee your untimed C/C++ > code is equivalent to the produced RTL. Calypto can do this but I am > sure this is outside the EDA budget for most of us. > > If I find a critical path during synthesis, how easy is this to link > back to the BSV code? BSV preserves names from the target code into its generated Verilog, which is reasonably understandable if not particularly editable. It looks like a big pile of always @(posedge clock) nextstate <= combinational_fn( previousstate ) which tools handle just fine. The name preservation means that debugging it using Verilog tools like SignalTap/Chipscope is feasible and, if you know what the BSV was supposed to be doing you can generally follow that through to the Verilog. Similarly, the name in the synthesis tool can be tracked back to the BSV (though obviously, don't expect the combinational logic at that stage to look the same as the combinational logic in your source). You do need to understand a bit what's going on - if you make an enormous mux then it'll be slow, and since it makes it easier to write things you can also write enormous slow things if you aren't paying attention. (I once wrote the whole of SHA256 as a single-cycle combinational function, which took about a dozen lines of BSV. It crashed Quartus ;-) There aren't any tools to my knowledge that check equivalence between the BSV source and the RTL, but then that's a bit like checking equivalence between your C++ source code and your assembly output - if it fails, it's a compiler bug. TheoArticle: 160744
On 28/10/2018 18:27, Theo wrote: > HT-Lab <hans64@htminuslab.com> wrote: .. > There aren't any tools to my knowledge that check equivalence between the > BSV source and the RTL, but then that's a bit like checking equivalence > between your C++ source code and your assembly output - if it fails, it's a > compiler bug. Yes but C++ to assembly is sequential to sequential (there are exceptions), I am talking about sequential to concurrent which is a different kettle of fish. I suspect I don't fully understand the flow control aspect BSV adds to the language. However, one good reason for having a BSV to RTL equivalence checker is that it allows BSV to be used for DO-254/ISOxx type of projects. In those cases you need to prove the translation by a second source, using a formal tool which mathematically proves the sources are identical is becoming a must have for DO-254 projects. Hans www.ht-lab.com > > Theo >Article: 160745
HT-Lab <hans64@htminuslab.com> wrote: > On 28/10/2018 18:27, Theo wrote: > > HT-Lab <hans64@htminuslab.com> wrote: > .. > > There aren't any tools to my knowledge that check equivalence between the > > BSV source and the RTL, but then that's a bit like checking equivalence > > between your C++ source code and your assembly output - if it fails, it's a > > compiler bug. > > Yes but C++ to assembly is sequential to sequential (there are > exceptions), I am talking about sequential to concurrent which is a > different kettle of fish. BSV is similar - timing is explicit. It's just that the stuff like always @(posedge clock) begin if (reset) begin ... end if (complicated_valid_expression) begin ... end end is handled for you. In other words, if you have a pipeline it'll take exactly the number of cycles you told it, but it could starve or deadlock if you did something wrong. One solution to that is to write code that has a fallback case so it'll never deadlock (eg propagate a token that's explicitly Invalid rather than stalling waiting for the next token with valid data). BSV doesn't do any transformations from sequential to concurrent - if you write sequential you get sequential (there's some handy constructs for building state machines), if you write concurrent (the default) you get concurrent. > I suspect I don't fully understand the flow control aspect BSV adds to > the language. However, one good reason for having a BSV to RTL > equivalence checker is that it allows BSV to be used for DO-254/ISOxx > type of projects. In those cases you need to prove the translation by a > second source, using a formal tool which mathematically proves the > sources are identical is becoming a must have for DO-254 projects. True. There are formal tools for BSV, but they tend to approach BSV from its underlying Haskell roots, rather than looking at the gory details of the verilog output. Since the compiler emits a schedule which essentially shows its working, I suppose it could be done. TheoArticle: 160746
Am Sonntag, 28. Oktober 2018 12:51:11 UTC+1 schrieb Theo: > > > 'signal x : std_logic_vector(31 downto 0)' when I could just type > So if I was writing in a strongly typed language rather than a disaster like > Verilog, it would be: > > Reg#(UInt#(32)) No. In VHDL there is a difference between A(31 downto 0), B(0 to 31) and C(32 downto 1). Your example would remove that information. For a common bit vector that seems ridiculous overspecified, but for complex structures it is good to have that difference. bye ThomasArticle: 160747
Thomas Stanka <usenet_nospam_valid@stanka-web.de> wrote: > In VHDL there is a difference between A(31 downto 0), B(0 to 31) and C(32 > downto 1). Your example would remove that information. For a common bit > vector that seems ridiculous overspecified, but for complex structures it > is good to have that difference. For what case would it make sense to distinguish between those, but not use Structure.fieldname notation? And where B(0 to 31) makes sense but reverse(B(31 downto 0)) doesn't? (in other words, in the rare case you want something that isn't the norm, you have to express that explicitly - rather than forcing you to express the norm explicitly at all times) TheoArticle: 160748
On Wednesday, October 31, 2018 at 10:55:50 AM UTC-4, Theo wrote: > Thomas Stanka <usenet_nospam_valid@stanka-web.de> wrote: > > In VHDL there is a difference between A(31 downto 0), B(0 to 31) and C(32 > > downto 1). Your example would remove that information. For a common bit > > vector that seems ridiculous overspecified, but for complex structures it > > is good to have that difference. > > For what case would it make sense to distinguish between those, but not use > Structure.fieldname notation? > > And where B(0 to 31) makes sense but reverse(B(31 downto 0)) doesn't? > > (in other words, in the rare case you want something that isn't the norm, > you have to express that explicitly - rather than forcing you to express the > norm explicitly at all times) Unfortunately I don't follow your descriptions of the BSV language enough to compare to VHDL. The examples you show don't seem to be so much more terse than VHDL unless you are literally talking about the fact that the names of VHDL keywords are longer. signal foo unsigned(31 downto 0); foo <= bar + barfoo; This would be what in BSV? This is not something I've complained about ever and the issues I did mention weren't addressed by you I think. Is there are summary of the language somewhere to give a reasonable understanding rather than a full blown treatment of the language? That is one strike against VHDL. Getting up the learning curve takes some time and effort. Rick C.Article: 160749
gnuarm.deletethisbit@gmail.com wrote: > Unfortunately I don't follow your descriptions of the BSV language enough > to compare to VHDL. The examples you show don't seem to be so much more > terse than VHDL unless you are literally talking about the fact that the > names of VHDL keywords are longer. > > signal foo unsigned(31 downto 0); > foo <= bar + barfoo; > > This would be what in BSV? This is not something I've complained about > ever and the issues I did mention weren't addressed by you I think. The direct equivalent would be: Reg#(UInt#(32)) foo <- mkReg(99); // reset value 99 rule nameoftherule; // happens every clock cycle if 'bar' and 'barfoo' are ready foo <= bar + barfoo; endrule but that also handles the clock and reset conditions for you as well. My main beef with VHDL verbosity is about interfaces, and the screeds of code that end up being written to connect a thing inside a module to the outside of the module, with a 1:1 correspondence between wires. You end up declaring all the wires three times - once as the definition of the interface of the parent module, once of the definition of the interface in the child module, and once inside the module when you want to connect A to B. VHDL does support interfaces (where you just define the bundle of wires only once), but I don't see that in codebases. Does it lack tools support? > Is there are summary of the language somewhere to give a reasonable > understanding rather than a full blown treatment of the language? That is > one strike against VHDL. Getting up the learning curve takes some time > and effort. The BSV By Example book is quite good: http://csg.csail.mit.edu/6.S078/6_S078_2012_www/resources/bsv_by_example.pdf There's also a toy BSV compiler here that I haven't played with: https://www.cl.cam.ac.uk/~djg11/wwwhpr/toy-bluespec-compiler.html (it seems to be a DSL in F#, so not something you can directly feed .bsv files) 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