EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

FPGA Market Entry Barriers

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - FPGA Market Entry Barriers

Goto page Previous  1, 2, 3, 4


Guest

Sun Oct 28, 2018 2:45 pm   



On Sunday, October 28, 2018 at 7:51:11 AM UTC-4, Theo wrote:
Quote:
gnuarm.deletethisbit_at_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.

HT-Lab
Guest

Sun Oct 28, 2018 7:45 pm   



On 27/10/2018 22:57, Theo wrote:
Quote:
HT-Lab <hans64_at_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.

Quote:

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.

Quote:

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.

Quote:
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?

Quote:
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

Quote:

Theo


Theo
Guest

Sun Oct 28, 2018 7:45 pm   



gnuarm.deletethisbit_at_gmail.com wrote:
Quote:
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).

Quote:
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'.

HT-Lab
Guest

Sun Oct 28, 2018 7:45 pm   



On 28/10/2018 13:00, gnuarm.deletethisbit_at_gmail.com wrote:
Quote:
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

Quote:

Rick C.


Theo
Guest

Sun Oct 28, 2018 7:45 pm   



HT-Lab <hans64_at_htminuslab.com> wrote:
Quote:
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.

Theo

HT-Lab
Guest

Sun Oct 28, 2018 8:45 pm   



On 28/10/2018 18:27, Theo wrote:
Quote:
HT-Lab <hans64_at_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


Quote:

Theo


Theo
Guest

Sun Oct 28, 2018 9:45 pm   



HT-Lab <hans64_at_htminuslab.com> wrote:
Quote:
On 28/10/2018 18:27, Theo wrote:
HT-Lab <hans64_at_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.

Quote:
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.

Theo

Thomas Stanka
Guest

Wed Oct 31, 2018 2:45 pm   



Am Sonntag, 28. Oktober 2018 12:51:11 UTC+1 schrieb Theo:
Quote:
'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 Thomas

Theo
Guest

Wed Oct 31, 2018 4:45 pm   



Thomas Stanka <usenet_nospam_valid_at_stanka-web.de> wrote:
Quote:
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)

Theo


Guest

Wed Oct 31, 2018 4:45 pm   



On Wednesday, October 31, 2018 at 10:55:50 AM UTC-4, Theo wrote:
Quote:
Thomas Stanka <usenet_nospam_valid_at_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.

Theo
Guest

Wed Oct 31, 2018 8:45 pm   



gnuarm.deletethisbit_at_gmail.com wrote:
Quote:
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?

Quote:
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

HT-Lab
Guest

Thu Nov 01, 2018 9:45 am   



On 31/10/2018 19:27, Theo wrote:
> gnuarm.deletethisbit_at_gmail.com wrote:
...
Hi Theo,

Quote:
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?


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

http://www.eda-twiki.org/twiki/pub/P1076/PrivateDocuments/P1076-2018.pdf

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

Regards,
Hans
www.ht-lab.com

Quote:

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



Guest

Thu Nov 01, 2018 6:45 pm   



On Thursday, November 1, 2018 at 4:06:04 AM UTC-4, HT-Lab wrote:
Quote:
On 31/10/2018 19:27, Theo wrote:
gnuarm.deletethisbit_at_gmail.com wrote:
..
Hi Theo,

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?

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

http://www.eda-twiki.org/twiki/pub/P1076/PrivateDocuments/P1076-2018.pdf

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


Maybe by 2028.

Rick C.

Goto page Previous  1, 2, 3, 4

elektroda.net NewsGroups Forum Index - FPGA - FPGA Market Entry Barriers

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map