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  Next

Michael Kellett
Guest

Sat Oct 27, 2018 3:45 pm   



On 27/10/2018 04:38, gnuarm.deletethisbit_at_gmail.com wrote:
Quote:
On Friday, October 26, 2018 at 10:25:57 PM UTC-4, Kevin Neilson wrote:
That may be, but expired patents aren't really significant. The basic functionality of the LUT/FF and routing have been available for quite some time now. The details of FPGA architectures only matter when you are competing head to head. That's why Silicon Blue focused on a market segment that was ignored by the big players. The big two chase the telecom market with max capacity, high pin count barn burners and the other markets are addressed with the same technology making it impossible to compete in the low power areas. In the end no significant user who is considering an iCE40 part even looks at a part from Xilinx or Altera.

Rick C.

I don't do hobbyist stuff anymore since I'm too busy with work but I would think one could just use eval boards. I don't know why a DIP would be required. I don't know about the cost of the tools for a hobbyist, though.

Tools are zero cost, no? I bought tools once, $1500 I believe. Ever since I just use the free versions.


As for the high pin counts, I would think that the need would be mitigated with all the high-speed serial interfaces.

Uh, tell that to Xilinx, Altera, Lattice and everyone else (which I guess means Microsemi). Lattice has some low pin count parts for the iCE40 line, but they are very fine pitch BGA type devices which are hard to route. Otherwise the pin counts tend to be much higher than what I consider to be a similar MCU if not high pin count by all measures.

Rick C.

Lattice have some ice40 series parts in 48pin 0.5mm pitch QFN, easily
hotplate and hand solderable.
Altera have MAX10 with 50kLUTs (approx) in 144 pin TQFP.
There are no modern Xilinx parts in other than BGA but you can get Artix
and Spartan 7 in 1mm pitch BGA. Should be possible to use on low cost
(0.15mm track and gap) 4 layer boards.
I mean to try quite soon - I'll let you know.

MK

HT-Lab
Guest

Sat Oct 27, 2018 6:45 pm   



On 27/10/2018 13:12, Theo wrote:
...
Quote:
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.
Quote:

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.


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

Quote:

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?

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


Quote:

Theo


Kevin Neilson
Guest

Sat Oct 27, 2018 9:45 pm   



Quote:
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 inherently 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* medium or target.

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 abstraction". 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 target.


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 printf() 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 projects like that, because those are done in microcontrollers.

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

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() methods. 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 parallel; 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 maintain.


Kevin Neilson
Guest

Sat Oct 27, 2018 9:45 pm   



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


This is the problem I run into all the time. No matter how low-level I write 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 from 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 might 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 that already works.

Kevin Neilson
Guest

Sat Oct 27, 2018 9:45 pm   



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



Guest

Sat Oct 27, 2018 10:45 pm   



On Saturday, October 27, 2018 at 5:36:40 AM UTC-4, HT-Lab wrote:
Quote:
On 27/10/2018 07:22, gnuarm.deletethisbit_at_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 SystemVerilog. What takes months is converting to a parallelized design, adding pipelining, meeting timing, placing, dealing with domain crossings, instantiating 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 that looks like assembly, in which the actual algorithm is indiscernible without extensive comments.

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 inherently 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* medium or target.

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 abstraction". 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 target.


Well said.

..

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 use gray counters to easily infer fifos. Typically the thing that slows me down in HDL is the fact that I'm using VHDL with all it's verbosity.

really, what aspect of VHDL is slowing you down that would be quicker in
Verilog?

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, but it is far from justifying that VHDL isn't verbose.

One of the most verbose aspects of VHDL is the need to type signals three times when instantiating modules. 1) typing the module, 2) typing the instance, 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 avoid 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.


Quote:
Personally I think verbosity is a good thing as it makes it easier to
understand somebody else's code.


Sure, that's no small reason why I haven't switched. The guys who's Verilog code I see seem to eschew white space and cram it all together. I find that alone to make the code hard to read. But it's all about what you are used to really. They seem to get along just fine.


Quote:
Some tools help with that, but I don't have those. I've just never bitten the bullet to try working much in Verilog.

I would forget about Verilog as it has too many quirks, go straight to
SystemVerilog (or just stick with VHDL).


I'm not doing much with any HDL so little chance of working with anything other than VHDL at the moment.

These days I mostly receive POs and issue POs.

Rick


Guest

Sat Oct 27, 2018 10:45 pm   



On Saturday, October 27, 2018 at 8:12:05 AM UTC-4, Theo wrote:
Quote:
HT-Lab <hans64_at_htminuslab.com> wrote:
On 27/10/2018 07:22, gnuarm.deletethisbit_at_gmail.com wrote:
On Saturday, October 27, 2018 at 12:30:55 AM UTC-4, Kevin Neilson wrote:

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 use gray counters to easily infer fifos. Typically
the thing that slows me down in HDL is the fact that I'm using VHDL
with all it's verbosity.

really, what aspect of VHDL is slowing you down that would be quicker in
Verilog?

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

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.

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 clear to be explicit.


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


It's not quite that bad. The tools support what the users request. So the most often used features are supported in most tools.


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


What about simulation? Is the BSV simulated or the Verilog?


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


How do you distinguish code that is combinatorial?

Rick C.


Guest

Sat Oct 27, 2018 11:45 pm   



On Saturday, October 27, 2018 at 9:52:13 AM UTC-4, Michael Kellett wrote:
Quote:

Lattice have some ice40 series parts in 48pin 0.5mm pitch QFN, easily
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 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.


Quote:
There are no modern Xilinx parts in other than BGA but you can get Artix
and Spartan 7 in 1mm pitch BGA. Should be possible to use on low cost
(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.

Theo
Guest

Sat Oct 27, 2018 11:45 pm   



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

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

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

Also, being polymorphic, you can generate a variety of different modules from
the one description - which saves a lot of repetition.

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

Theo


Guest

Sat Oct 27, 2018 11:45 pm   



On Saturday, October 27, 2018 at 4:14:59 PM UTC-4, Kevin Neilson wrote:
Quote:
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 inherently 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* medium or target.

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 abstraction". 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 target.

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 printf() 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 projects 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 an MCU.


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

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() methods. 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 parallel; 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 maintain.


But if it isn't supported in synthesis, what good is it? If I am coding for simulation only I can take all manner of shortcuts.

Rick C.

Theo
Guest

Sat Oct 27, 2018 11:45 pm   



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

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

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

Theo
Guest

Sun Oct 28, 2018 12:45 am   



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

Theo


Guest

Sun Oct 28, 2018 7:45 am   



On Saturday, October 27, 2018 at 6:41:44 PM UTC-4, Theo wrote:
Quote:
gnuarm.deletethisbit_at_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?


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


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


Guest

Sun Oct 28, 2018 7:45 am   



On Saturday, October 27, 2018 at 7:02:56 PM UTC-4, Theo wrote:
Quote:
gnuarm.deletethisbit_at_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!


You mean like power and ground? I recall one type of BGA that has concentric 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 center as it results in shorter, lower inductance paths inside the chip package. So those pretty much always need vias between the pads.

Rick C.

Theo
Guest

Sun Oct 28, 2018 1:45 pm   



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

Theo

Goto page Previous  1, 2, 3, 4  Next

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