FPGA Market Entry Barriers

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 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)

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.

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)

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

Reply to
Theo
Loading thread data ...

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!

Theo

Reply to
Theo

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?

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.

I guess you are stuck with the one vendor then, although I shouldn't use a loaded word like "stuck".

Rick C.

Reply to
gnuarm.deletethisbit

I

y to

t

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.

Rick C.

Reply to
gnuarm.deletethisbit

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).

Theo

Reply to
Theo

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.

Reply to
gnuarm.deletethisbit

..

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.

OK, I will give you that one. As we all know switching between vendors always requires work.

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.

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?

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

formatting link

Reply to
HT-Lab

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 Verilog has always confused me with reg and wire (I think). I've never

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

Reply to
Theo

..

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.

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

formatting link

Reply to
HT-Lab

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

Reply to
Theo

..

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

formatting link

Reply to
HT-Lab

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.

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.

Theo

Reply to
Theo

Am Sonntag, 28. Oktober 2018 12:51:11 UTC+1 schrieb Theo:

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 Thomas

Reply to
Thomas Stanka

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)

Theo

Reply to
Theo

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

Reply to
gnuarm.deletethisbit

The direct equivalent would be:

Reg#(UInt#(32)) foo

Reply to
Theo

.. Hi Theo,

Interfaces are not yet supported but they are coming with VHDL2018, see section 6.5 of the draft VHDL2018 LRM:

formatting link

Unfortunately as all VHDL designers will know we won't see EDA vendors adopting VHDL2018 any time soon.

Regards, Hans

formatting link

Reply to
HT-Lab

Maybe by 2028.

Rick C.

Reply to
gnuarm.deletethisbit

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.