On Thursday, November 1, 2018 at 4:06:04 AM UTC-4, HT-Lab wrote:
> On 31/10/2018 19:27, Theo wrote:
> > gnuarm.deletethisbit@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.
Reply by HT-Lab●November 1, 20182018-11-01
On 31/10/2018 19:27, Theo wrote:
> gnuarm.deletethisbit@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.
Regards,
Hans
www.ht-lab.com
>
>> 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
>
Reply by Theo●October 31, 20182018-10-31
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.
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.
Reply by Theo●October 31, 20182018-10-31
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)
Theo
Reply by Thomas Stanka●October 31, 20182018-10-31
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 Thomas
Reply by Theo●October 28, 20182018-10-28
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.
Theo
Reply by HT-Lab●October 28, 20182018-10-28
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
>
Reply by Theo●October 28, 20182018-10-28
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.
Theo
Reply by HT-Lab●October 28, 20182018-10-28
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