Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 159050

Article: 159050
Subject: Re: Lattice MachXO2 breakout board - replacing FPGA with different
From: rickman <gnuarm@gmail.com>
Date: Fri, 8 Jul 2016 14:57:15 -0400
Links: << >>  << T >>  << A >>
On 7/8/2016 12:26 PM, Brane2 wrote:
> Hi,
>
> I have a couple of that neat boards with XO2-7000 and not much else.
>
> I managed to burn the FPGA on one of them and since Farnell didn't have the exact 7000HE model that was on the board, I used 7000HC and bridged VCC so that chips gets 3.3V for core power that it wants.
>
> But now I can't program it through FTDI. I've noticed several variations of the board. Some had XO2-1200 while mine have XO2-7000HE.
>
> Shoould this with pin-compatible chip just work or do I have to have different EEPROM content for FTDI ?
>
> BTW, trivial "blinkenled" example on _this_ board  fails with:
>
> *************
> Device#1 LCMXO2-7000HC: Failed to verify the ID
> (Expected: 0x012BD043 Read: 0xFFFFFFFE).
>
> ERROR - Check configuration setup: Unsuccessful.
>
> ERROR: pgr_program failed.
>
> ERROR - Programming failed.
> **********
>
> If it doesn't work through FTDI, I'll use ISP cable on it, but it's nuisance...

I'm not sure what's wrong.  If the ID were all 1's, I'd say it was a bad 
solder joint, but with the lone 0 in the returned ID that doesn't seem 
to fit.  Still, that ID is just not right either and it would seem 
something is wrong with the JTAG.  Is the "expected" ID for a 7000HC or 
a 7000HE?

-- 

Rick C

Article: 159051
Subject: Re: Lattice Diamond and VHDL-2008
From: Brane2 <brankob@avtomatika.com>
Date: Sat, 9 Jul 2016 08:12:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dne petek, 08. julij 2016 20.53.43 UTC+2 je oseba rickman napisala:
> On 7/8/2016 9:57 AM, GaborSzakacs wrote:
> > rickman wrote:
> >>
> >> Meanwhile, I also asked if the bitstream files were the same for the
> >> LFXP3E-3TN100C and LFXP3C-3TN100C and they said I should re-generate
> >> the bitstream.  The only difference should be that one uses an
> >> external 1.2 volt core supply and the other has internal LDOs to work
> >> off 3.3 volts. Would that really result in any difference in the
> >> bitstream?  I don't want to have to regenerate the bitstream since it
> >> would require re-qualification.  I'm tempted to try it.  I don't have
> >> much confidence in the support.
> >>
> >
> > It's certainly worth a try, but if Lattice is anything like Xilinx,
> > there would be at a minimum a different device ID and the programming
> > tools would detect the difference and refuse to program the part.
> 
> I talked to a local FAE and he said he thought they used the same die 
> with different bond out.  I can't get support to acknowledge they use 
> the same bit stream, but maybe I can get them to say it is the same die. 
>   If so, the ID would have to be the same.
> 
> -- 
> 
> Rick C

FWIW, I have finally solved my Breakout Board problem and so now I can check the difference between XO2-7000HC/HE, which is of the same nature:

XO2-7000HC: ID= 0x012BD043
XO2-7000HE: ID= 0x012B5043

Interestingly, I had that old basic blinking leds demo for Breakout Board, that was done for HE chip and Programmer utility refused to burn it into HC chip.

But then I made new design with same Verilog file ( just regenerated power controller with IPExpress) for HC chip to test new board and that one I managed to burn into HC as well as HE chip.
Perhaps because I have had generated jedec as well as bitstream file this time and programmer managed to use jedec...









Article: 159052
Subject: Re: need some help with altera quartus
From: Andy McClelland <andy@cambeamsystemdesign.co.uk>
Date: Mon, 11 Jul 2016 04:18:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, July 5, 2016 at 11:03:08 PM UTC+1, kristoff wrote:
> Hi all,
> 
> 
> To learn VHDL and FPGAs, I bought a number of boards, one of them being 
> this one: 
> http://www.aliexpress.com/item/EP4CE10-altera-fpga-board-fpga-development-board-fpga-altera-board-fpga-development-board/32637947021.html
> 
> It's a Altera cyclone IV with 16 Mbit of serial flash (M25P16/EPSC16) to 
> store the configuration file.
> 
> Next to that, I have a USB Blaster.
> 
> 
> 
> Now, I am able to create a "blinky" test design and program the device 
> using the "jtag" programming mode, but -of course- in this senario the 
> configuration is lost after a reset or power-cycle.
> 
> 
> Can somebody explain how exactly to program this device so that the 
> configuration is stored inthe serial flash device?
> 
> 
> Sofar, I found that
> - in the programmer, you can add a flash-device to the fpga chip
> - there are things called "secundary programing files" and there is an 
> option "convert programming files" under the "files"-menu.
> 
> But, for the rest, the more I read quarus help website, the less I 
> understand this all. The number of files and options there exists only 
> seams to go up and -as we say in dutch- it's become very hard to see the 
> forest through the trees. :-(
> 
> 
> Can somebody give a little more information what exactly I need for 
> this? Exactly what file do I need to create?
> 
> 
> Any help is welcome!


Perhaps this application note will answer your question:

https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an370.pdf

-- 
Andy McC

Article: 159053
Subject: Re: Lattice Diamond and VHDL-2008
From: GaborSzakacs <gabor@alacron.com>
Date: Mon, 11 Jul 2016 17:28:53 -0400
Links: << >>  << T >>  << A >>
rickman wrote:
> On 7/8/2016 9:57 AM, GaborSzakacs wrote:
>> rickman wrote:
>>>
>>> Meanwhile, I also asked if the bitstream files were the same for the
>>> LFXP3E-3TN100C and LFXP3C-3TN100C and they said I should re-generate
>>> the bitstream.  The only difference should be that one uses an
>>> external 1.2 volt core supply and the other has internal LDOs to work
>>> off 3.3 volts. Would that really result in any difference in the
>>> bitstream?  I don't want to have to regenerate the bitstream since it
>>> would require re-qualification.  I'm tempted to try it.  I don't have
>>> much confidence in the support.
>>>
>>
>> It's certainly worth a try, but if Lattice is anything like Xilinx,
>> there would be at a minimum a different device ID and the programming
>> tools would detect the difference and refuse to program the part.
> 
> I talked to a local FAE and he said he thought they used the same die 
> with different bond out.  I can't get support to acknowledge they use 
> the same bit stream, but maybe I can get them to say it is the same die. 
>  If so, the ID would have to be the same.
> 

The same die can have a different ID if there are bonding options that
affect the ID.  Xilinx goes even farther with the Artix-7 series,
unabashedly selling the same part/package with a smaller number
of usable fabric elements.  Their device ID might be affected by
some internal bonding or by OTP programming.  In any case it's only
their tools that prevent you from using the "smaller" part as the
larger one.  The die is identical, and the bitstreams are identical
other than the ID.  If you open a design for the smaller part in
the layout view, you can see the full complement of internal
elements of the larger part.  You can also place your components
anywhere in the die.  The only restriction is the number of each
element type you are allowed to map into the part.

-- 
Gabor

Article: 159054
Subject: Re: Lattice Diamond and VHDL-2008
From: rickman <gnuarm@gmail.com>
Date: Mon, 11 Jul 2016 21:38:09 -0400
Links: << >>  << T >>  << A >>
On 7/11/2016 5:28 PM, GaborSzakacs wrote:
> rickman wrote:
>> On 7/8/2016 9:57 AM, GaborSzakacs wrote:
>>> rickman wrote:
>>>>
>>>> Meanwhile, I also asked if the bitstream files were the same for the
>>>> LFXP3E-3TN100C and LFXP3C-3TN100C and they said I should re-generate
>>>> the bitstream.  The only difference should be that one uses an
>>>> external 1.2 volt core supply and the other has internal LDOs to work
>>>> off 3.3 volts. Would that really result in any difference in the
>>>> bitstream?  I don't want to have to regenerate the bitstream since it
>>>> would require re-qualification.  I'm tempted to try it.  I don't have
>>>> much confidence in the support.
>>>>
>>>
>>> It's certainly worth a try, but if Lattice is anything like Xilinx,
>>> there would be at a minimum a different device ID and the programming
>>> tools would detect the difference and refuse to program the part.
>>
>> I talked to a local FAE and he said he thought they used the same die
>> with different bond out.  I can't get support to acknowledge they use
>> the same bit stream, but maybe I can get them to say it is the same
>> die.  If so, the ID would have to be the same.
>>
>
> The same die can have a different ID if there are bonding options that
> affect the ID.  Xilinx goes even farther with the Artix-7 series,
> unabashedly selling the same part/package with a smaller number
> of usable fabric elements.  Their device ID might be affected by
> some internal bonding or by OTP programming.  In any case it's only
> their tools that prevent you from using the "smaller" part as the
> larger one.  The die is identical, and the bitstreams are identical
> other than the ID.  If you open a design for the smaller part in
> the layout view, you can see the full complement of internal
> elements of the larger part.  You can also place your components
> anywhere in the die.  The only restriction is the number of each
> element type you are allowed to map into the part.

So much for the claim that they sell you the routing and give you the 
logic or free.

-- 

Rick C

Article: 159055
Subject: Re: Lattice MachXO2 breakout board - replacing FPGA with different
From: Brane2 <brankob@avtomatika.com>
Date: Tue, 12 Jul 2016 18:28:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dne petek, 08. julij 2016 20.57.18 UTC+2 je oseba rickman napisala:

> I'm not sure what's wrong.  If the ID were all 1's, I'd say it was a bad 
> solder joint, but with the lone 0 in the returned ID that doesn't seem 
> to fit.

I sorted it out. It works now. YEAH ! ;o)
BOard was damaged in very weid way. I seems that I managed to stab the board with something like Xacto knife in exactly the "right" spot - TDI line at ISP connector. It was so small it was practically invisible. 

After patching that track, XO2 Breakout Board works fine with HC chip now ;o)






  Still, that ID is just not right either and it would seem 
> something is wrong with the JTAG.  Is the "expected" ID for a 7000HC or 
> a 7000HE?
> 
> -- 
> 
> Rick C


Article: 159056
Subject: Re: Lattice MachXO2 breakout board - replacing FPGA with different
From: rickman <gnuarm@gmail.com>
Date: Tue, 12 Jul 2016 22:05:19 -0400
Links: << >>  << T >>  << A >>
On 7/12/2016 9:28 PM, Brane2 wrote:
> Dne petek, 08. julij 2016 20.57.18 UTC+2 je oseba rickman napisala:
>
>> I'm not sure what's wrong.  If the ID were all 1's, I'd say it was a bad
>> solder joint, but with the lone 0 in the returned ID that doesn't seem
>> to fit.
>
> I sorted it out. It works now. YEAH ! ;o)
> BOard was damaged in very weid way. I seems that I managed to stab the board with something like Xacto knife in exactly the "right" spot - TDI line at ISP connector. It was so small it was practically invisible.
>
> After patching that track, XO2 Breakout Board works fine with HC chip now ;o)

Yes, that makes more sense.  A floating TDI line could result in nearly 
anything being returned.  I thought the tool had a diagnostic mode that 
would tell you that sort of thing.  But maybe you have to select that.

I build a board with an XP device and used to do all the testing myself. 
  Every once in awhile I would get a flaky JTAG connection and it would 
report what it thought was wrong.  That was using the programming 
software with the old classic tools, but that should be the same with 
the diamond tools.

-- 

Rick C

Article: 159057
Subject: Lattice Diamond 3.7 and Synplify
From: rickman <gnuarm@gmail.com>
Date: Thu, 21 Jul 2016 14:18:36 -0400
Links: << >>  << T >>  << A >>
I am trying to run the latest version of Lattice Diamond free edition. 
When I attempt to synthesize through the Diamond GUI I get "error code 
3".  I've opened a ticket with Lattice support but after 2 weeks I am 
not getting anywhere with them.  If there isn't something simple wrong 
with my project, they can't seem to be of much help and take two days to 
respond to every comment I make.

Here is the full text of the log.  Anyone know what Error 3 is?  I 
believe error 2 is a license issue.  The report says to contact Synopsys 
for support, but they don't support the free tools.  I have uninstalled 
and reinstalled the tools already.  This is getting old.




Starting: "prj_run Synthesis -impl impl1"


************************************************************
**  Synplify Pro                                          **
************************************************************

synpwrap -msg -prj "TestProj_impl1_synplify.tcl" -log "TestProj_impl1.srf"
Copyright (C) 1992-2016 Lattice Semiconductor Corporation. All rights 
reserved.
Lattice Diamond Version 3.7.0.96.1
INFO - Synplify synthesis engine is launched.
Error of dumping file TestProj_impl1.srf, 'stdout.log' is instead.

==contents of stdout.log
Please open a web case about this problem. A Synopsys CAE will then 
contact you.

Instructions to open a web-case:

1.  Go to the Synopsys support web site, https://solvnet.synopsys.com.

2.  Login with you user name and  password. If you do not have an 
account, please register and set it up.

3.  Click the  'Enter A Call' link.

4.  Provide a detailed description of the problem, and fill in all 
required fields.

5.  Attach any test cases or archived project files required to 
reproduce the problem.




Synthesis exit by 3.
Done: error code 3

-- 

Rick C

Article: 159058
Subject: Re: Lattice Diamond 3.7 and Synplify
From: Johann Klammer <klammerj@NOSPAM.a1.net>
Date: Fri, 22 Jul 2016 03:35:21 +0200
Links: << >>  << T >>  << A >>
On 07/21/2016 08:18 PM, rickman wrote:
[...]
> 
> 
> Synthesis exit by 3.
> Done: error code 3
> 

Is your box a 32bit one?


Article: 159059
Subject: Re: Lattice Diamond 3.7 and Synplify
From: rickman <gnuarm@gmail.com>
Date: Thu, 21 Jul 2016 21:50:08 -0400
Links: << >>  << T >>  << A >>
On 7/21/2016 9:35 PM, Johann Klammer wrote:
> On 07/21/2016 08:18 PM, rickman wrote:
> [...]
>>
>>
>> Synthesis exit by 3.
>> Done: error code 3
>>
>
> Is your box a 32bit one?

64 bit and I installed the 64 bit version of Diamond.

-- 

Rick C

Article: 159060
Subject: Re: Lattice Diamond 3.7 and Synplify
From: rickman <gnuarm@gmail.com>
Date: Thu, 21 Jul 2016 22:20:41 -0400
Links: << >>  << T >>  << A >>
On 7/21/2016 9:50 PM, rickman wrote:
> On 7/21/2016 9:35 PM, Johann Klammer wrote:
>> On 07/21/2016 08:18 PM, rickman wrote:
>> [...]
>>>
>>>
>>> Synthesis exit by 3.
>>> Done: error code 3
>>>
>>
>> Is your box a 32bit one?
>
> 64 bit and I installed the 64 bit version of Diamond.

I had initially installed the 32 bit version I believe and uninstalled 
it before installing the 64 bit version.

I find it odd that tech support seems to be unable to answer such a 
simple  question as what is error code 3 in Synplify?  What is the point 
of returning error codes if no one knows what they mean???

-- 

Rick C

Article: 159061
Subject: Mod-24: The State of High-Level Synthesis in 2016
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Fri, 22 Jul 2016 09:43:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
It's 2016 and I still have to write out most of my code at very low levels =
of abstraction like I did ten years ago.  Whenever I hear about a new tool =
that supposedly converts C to gates, I don't even look into it, because I c=
an't even get Verilog to synth properly.

My latest example:  I needed to reduce an 12-bit number, mod-24.

input [11:0] x;
always@(posedge clk) xmod24 <=3D x%24;

When I put this in Vivado, what do I get?  40 LUTs (plus some carry chains)=
 and 10 levels of logic.  TEN.  Needless to say, that won't meet timing at =
350MHz, especially when it involves getting on and off a bunch of little ca=
rry chains.

So then I have to go down a level of abstraction:

input [11:0];
// x%24 =3D 8*(floor(x/8)%3) + x%8
always@(posedge clk)
  xmod24 <=3D {x[11:3]%3, x[2:0]};=20

Now I get 4 LUTs and TWO levels of logic.  TWO.  At least I didn't have to =
instantiate primitives, like I still often do, even though it's 2016.

Needless to say, I am not about to waste a bunch of time trying out any new=
 "high-level synthesis" tools.

Article: 159062
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Allan Herriman <allanherriman@hotmail.com>
Date: 23 Jul 2016 03:35:22 GMT
Links: << >>  << T >>  << A >>
On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote:

> It's 2016 and I still have to write out most of my code at very low 
levels of abstraction like I did ten years ago.  Whenever I hear about a 
new tool that supposedly converts C to gates, I don't even look into it, 
because I can't even get Verilog to synth properly.
> 
> My latest example:  I needed to reduce an 12-bit number, mod-24.
> 
> input [11:0] x;
> always@(posedge clk) xmod24 <= x%24;
> 
> When I put this in Vivado, what do I get?  40 LUTs (plus some carry 
chains) and 10 levels of logic.  TEN.  Needless to say, that won't meet 
timing at 350MHz, especially when it involves getting on and off a bunch 
of little carry chains.
> 
> So then I have to go down a level of abstraction:
> 
> input [11:0];
> // x%24 = 8*(floor(x/8)%3) + x%8
> always@(posedge clk)
>   xmod24 <= {x[11:3]%3, x[2:0]}; 
> 
> Now I get 4 LUTs and TWO levels of logic.  TWO.  At least I didn't have 
to instantiate primitives, like I still often do, even though it's 2016.
> 
> Needless to say, I am not about to waste a bunch of time trying out any 
new "high-level synthesis" tools.


I find it easy to ignore HLS, but I still suffer from it because it 
splits the tool vendors' development budget across multiple tools.


I got all excited when I first heard about high level synthesis.  Then I 
discovered that the language was C - hardly high level, and not 
particularly well suited to the sorts of things that FPGA coders need to 
do.
It's not about making a better language though - it's about allowing non-
FPGA people to do FPGA things, all in the name of market share.


Allan

Article: 159063
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: rickman <gnuarm@gmail.com>
Date: Fri, 22 Jul 2016 23:59:57 -0400
Links: << >>  << T >>  << A >>
On 7/22/2016 11:35 PM, Allan Herriman wrote:
> On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote:
>
>> It's 2016 and I still have to write out most of my code at very low
> levels of abstraction like I did ten years ago.  Whenever I hear about a
> new tool that supposedly converts C to gates, I don't even look into it,
> because I can't even get Verilog to synth properly.
>>
>> My latest example:  I needed to reduce an 12-bit number, mod-24.
>>
>> input [11:0] x;
>> always@(posedge clk) xmod24 <= x%24;
>>
>> When I put this in Vivado, what do I get?  40 LUTs (plus some carry
> chains) and 10 levels of logic.  TEN.  Needless to say, that won't meet
> timing at 350MHz, especially when it involves getting on and off a bunch
> of little carry chains.
>>
>> So then I have to go down a level of abstraction:
>>
>> input [11:0];
>> // x%24 = 8*(floor(x/8)%3) + x%8
>> always@(posedge clk)
>>   xmod24 <= {x[11:3]%3, x[2:0]};
>>
>> Now I get 4 LUTs and TWO levels of logic.  TWO.  At least I didn't have
> to instantiate primitives, like I still often do, even though it's 2016.
>>
>> Needless to say, I am not about to waste a bunch of time trying out any
> new "high-level synthesis" tools.
>
>
> I find it easy to ignore HLS, but I still suffer from it because it
> splits the tool vendors' development budget across multiple tools.
>
>
> I got all excited when I first heard about high level synthesis.  Then I
> discovered that the language was C - hardly high level, and not
> particularly well suited to the sorts of things that FPGA coders need to
> do.
> It's not about making a better language though - it's about allowing non-
> FPGA people to do FPGA things, all in the name of market share.

I wouldn't say that.  I know when I have heard using C for synthesis 
discussed it is more about being able to write the entire project in C 
and pick multiple options for the hardware vs. software trade off.  I 
have no idea how realistic this might be.  But I don't think it is about 
suddenly having a vast pool of talent to design hardware.

-- 

Rick C

Article: 159064
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Emilian Miron <emilian.miron@gmail.com>
Date: Sat, 23 Jul 2016 08:58:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
I was pretty happy with Chisel for programming at a higher level. It's in S=
cala so it's a good blend of type safe but powerful and easy to write. It a=
lso catches silly Verilog errors like using an undeclared wire because of a=
 typo. Writing tests was also easier compared to Verilog. There's a sample =
Risc V core as well with various number of stages.

https://chisel.eecs.berkeley.edu/

On the down side, I did run into occasional issues with the framework and i=
t's harder to debug in hardware since the compiled version is pretty obfusc=
ated. The module inputs are there but other combinatorial glue logic and in=
ner wires had random names.. tried to fix that but ran into framework issue=
s with wire/register naming. It might be doable or I might have used it imp=
roperly but this was a hobby project and I did not have too much time to pu=
t into it.

On Saturday, July 23, 2016 at 12:00:03 AM UTC-4, rickman wrote:
> On 7/22/2016 11:35 PM, Allan Herriman wrote:
> > On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote:
> >
> >> It's 2016 and I still have to write out most of my code at very low
> > levels of abstraction like I did ten years ago.  Whenever I hear about =
a
> > new tool that supposedly converts C to gates, I don't even look into it=
,
> > because I can't even get Verilog to synth properly.
> >>
> >> My latest example:  I needed to reduce an 12-bit number, mod-24.
> >>
> >> input [11:0] x;
> >> always@(posedge clk) xmod24 <=3D x%24;
> >>
> >> When I put this in Vivado, what do I get?  40 LUTs (plus some carry
> > chains) and 10 levels of logic.  TEN.  Needless to say, that won't meet
> > timing at 350MHz, especially when it involves getting on and off a bunc=
h
> > of little carry chains.
> >>
> >> So then I have to go down a level of abstraction:
> >>
> >> input [11:0];
> >> // x%24 =3D 8*(floor(x/8)%3) + x%8
> >> always@(posedge clk)
> >>   xmod24 <=3D {x[11:3]%3, x[2:0]};
> >>
> >> Now I get 4 LUTs and TWO levels of logic.  TWO.  At least I didn't hav=
e
> > to instantiate primitives, like I still often do, even though it's 2016=
.
> >>
> >> Needless to say, I am not about to waste a bunch of time trying out an=
y
> > new "high-level synthesis" tools.
> >
> >
> > I find it easy to ignore HLS, but I still suffer from it because it
> > splits the tool vendors' development budget across multiple tools.
> >
> >
> > I got all excited when I first heard about high level synthesis.  Then =
I
> > discovered that the language was C - hardly high level, and not
> > particularly well suited to the sorts of things that FPGA coders need t=
o
> > do.
> > It's not about making a better language though - it's about allowing no=
n-
> > FPGA people to do FPGA things, all in the name of market share.
>=20
> I wouldn't say that.  I know when I have heard using C for synthesis=20
> discussed it is more about being able to write the entire project in C=20
> and pick multiple options for the hardware vs. software trade off.  I=20
> have no idea how realistic this might be.  But I don't think it is about=
=20
> suddenly having a vast pool of talent to design hardware.
>=20
> --=20
>=20
> Rick C


Article: 159065
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Sat, 23 Jul 2016 12:45:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
I guess the good news is that I'll have a job for a few years at least.  The machines are still pretty bad at my job.  

Article: 159066
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Sat, 23 Jul 2016 12:58:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
I remember going to a Celoxica Handel-C presentation long ago.  As I recall they did try to convince managers that any software person who wrote C could also design FPGAs with Handel-C. 



Article: 159067
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: rickman <gnuarm@gmail.com>
Date: Sat, 23 Jul 2016 17:11:44 -0400
Links: << >>  << T >>  << A >>
On 7/23/2016 3:58 PM, Kevin Neilson wrote:
> I remember going to a Celoxica Handel-C presentation long ago.  As I recall they did try to convince managers that any software person who wrote C could also design FPGAs with Handel-C.

Those people can also program FPGAs in VHDL.  Did they try to say it 
would take no training?

-- 

Rick C

Article: 159068
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Robert Walczyk <robertwalczyk@gmail.com>
Date: Sat, 23 Jul 2016 14:46:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
What about SDSoC Development Environment? Anyone with some hands on experience? I've seen a demo a few moths back and that looked promissing

Article: 159069
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Devas <geve115@gmail.com>
Date: Sun, 24 Jul 2016 23:48:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, July 23, 2016 at 6:00:03 AM UTC+2, rickman wrote:
> On 7/22/2016 11:35 PM, Allan Herriman wrote:
> > On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote:
> >
> >> It's 2016 and I still have to write out most of my code at very low
> > levels of abstraction like I did ten years ago.  Whenever I hear about =
a
> > new tool that supposedly converts C to gates, I don't even look into it=
,
> > because I can't even get Verilog to synth properly.
> >>
> >> My latest example:  I needed to reduce an 12-bit number, mod-24.
> >>
> >> input [11:0] x;
> >> always@(posedge clk) xmod24 <=3D x%24;
> >>
> >> When I put this in Vivado, what do I get?  40 LUTs (plus some carry
> > chains) and 10 levels of logic.  TEN.  Needless to say, that won't meet
> > timing at 350MHz, especially when it involves getting on and off a bunc=
h
> > of little carry chains.
> >>
> >> So then I have to go down a level of abstraction:
> >>
> >> input [11:0];
> >> // x%24 =3D 8*(floor(x/8)%3) + x%8
> >> always@(posedge clk)
> >>   xmod24 <=3D {x[11:3]%3, x[2:0]};
> >>
> >> Now I get 4 LUTs and TWO levels of logic.  TWO.  At least I didn't hav=
e
> > to instantiate primitives, like I still often do, even though it's 2016=
.
> >>
> >> Needless to say, I am not about to waste a bunch of time trying out an=
y
> > new "high-level synthesis" tools.
> >
> >
> > I find it easy to ignore HLS, but I still suffer from it because it
> > splits the tool vendors' development budget across multiple tools.
> >
> >
> > I got all excited when I first heard about high level synthesis.  Then =
I
> > discovered that the language was C - hardly high level, and not
> > particularly well suited to the sorts of things that FPGA coders need t=
o
> > do.
> > It's not about making a better language though - it's about allowing no=
n-
> > FPGA people to do FPGA things, all in the name of market share.
>=20
> I wouldn't say that.  I know when I have heard using C for synthesis=20
> discussed it is more about being able to write the entire project in C=20
> and pick multiple options for the hardware vs. software trade off.  I=20
> have no idea how realistic this might be.  But I don't think it is about=
=20
> suddenly having a vast pool of talent to design hardware.
>=20
> --=20
>=20
> Rick C

I attended a Xilinx meeting a couple of weeks ago. They told us that the ne=
w tools (e.g SDSoc) are created for a new pool of engineers, e.g software e=
ngineers, architects, etc. So this new pool of engineers is also able to de=
sign FPGAs. They showed a "nice" slide with a very small pool of FPGA engin=
eers and a very big pool of software engineers.


Article: 159070
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Allan Herriman <allanherriman@hotmail.com>
Date: 25 Jul 2016 10:38:56 GMT
Links: << >>  << T >>  << A >>
On Sun, 24 Jul 2016 23:48:46 -0700, Devas wrote:

> On Saturday, July 23, 2016 at 6:00:03 AM UTC+2, rickman wrote:
>> On 7/22/2016 11:35 PM, Allan Herriman wrote:
>> > On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote:
>> >
>> >> It's 2016 and I still have to write out most of my code at very low
>> > levels of abstraction like I did ten years ago.  Whenever I hear
>> > about a new tool that supposedly converts C to gates, I don't even
>> > look into it, because I can't even get Verilog to synth properly.
>> >>
>> >> My latest example:  I needed to reduce an 12-bit number, mod-24.
>> >>
>> >> input [11:0] x;
>> >> always@(posedge clk) xmod24 <= x%24;
>> >>
>> >> When I put this in Vivado, what do I get?  40 LUTs (plus some carry
>> > chains) and 10 levels of logic.  TEN.  Needless to say, that won't
>> > meet timing at 350MHz, especially when it involves getting on and off
>> > a bunch of little carry chains.
>> >>
>> >> So then I have to go down a level of abstraction:
>> >>
>> >> input [11:0];
>> >> // x%24 = 8*(floor(x/8)%3) + x%8 always@(posedge clk)
>> >>   xmod24 <= {x[11:3]%3, x[2:0]};
>> >>
>> >> Now I get 4 LUTs and TWO levels of logic.  TWO.  At least I didn't
>> >> have
>> > to instantiate primitives, like I still often do, even though it's
>> > 2016.
>> >>
>> >> Needless to say, I am not about to waste a bunch of time trying out
>> >> any
>> > new "high-level synthesis" tools.
>> >
>> >
>> > I find it easy to ignore HLS, but I still suffer from it because it
>> > splits the tool vendors' development budget across multiple tools.
>> >
>> >
>> > I got all excited when I first heard about high level synthesis. 
>> > Then I discovered that the language was C - hardly high level, and
>> > not particularly well suited to the sorts of things that FPGA coders
>> > need to do.
>> > It's not about making a better language though - it's about allowing
>> > non-
>> > FPGA people to do FPGA things, all in the name of market share.
>> 
>> I wouldn't say that.  I know when I have heard using C for synthesis
>> discussed it is more about being able to write the entire project in C
>> and pick multiple options for the hardware vs. software trade off.  I
>> have no idea how realistic this might be.  But I don't think it is
>> about suddenly having a vast pool of talent to design hardware.
>> 
>> --
>> 
>> Rick C
> 
> I attended a Xilinx meeting a couple of weeks ago. They told us that the
> new tools (e.g SDSoc) are created for a new pool of engineers, e.g
> software engineers, architects, etc. So this new pool of engineers is
> also able to design FPGAs. They showed a "nice" slide with a very small
> pool of FPGA engineers and a very big pool of software engineers.


Yay, Xilinx development money spent on another tool I'll never use.


In the meantime, I'm using ISE for my Virtex 6 designs (which I have to  
support until 2020-something).  Xilinx hasn't updated ISE since 2013.  ISE 
will never support the current versions of VHDL or Verilog.  Its bugs 
will never be fixed.


I'm sure this makes sense to the people in marketing.

Allan

Article: 159071
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 25 Jul 2016 11:45:20 +0100 (BST)
Links: << >>  << T >>  << A >>
Emilian Miron <emilian.miron@gmail.com> wrote:
> I was pretty happy with Chisel for programming at a higher level. It's in
> Scala so it's a good blend of type safe but powerful and easy to write. 
> It also catches silly Verilog errors like using an undeclared wire because
> of a typo.  Writing tests was also easier compared to Verilog.  There's a
> sample Risc V core as well with various number of stages.

Likewise we use Bluespec for much of our work.  Which AIUI Chisel is a
hardware construction language (ie it's in some ways a very powerful macro
language for Verilog, but the actual semantics are similar), Bluespec is
derived from Haskell.

Bluespec's unit of operation is the atomic rule.  You write rules which can
'fire' (perform their work) when the conditions are right.  Those conditions
can either be explicit (only fire in given conditions) but also implicit, so
you can write:

rule pipelineStage (freeze==False);
  let x = fifo1.deq();
  fifo2.enq(x);
endrule

As well as the explicit condition 'freeze==False' on the rule, fifo1.deq()
has an implicit condition - the rule will only fire (ie data enqueued into
fifo2) if fifo1 is exporting valid data.  There is no way to make a mistake
in the protocol and accidentally introduce invalid data.

Since Bluespec is derived from Haskell, polymorphism and higher order types
are part of the language DNA, so it's easy to make parameterisaed
components, and the FIFO semnatics makes it easy to plug them together.  The
above example is polymorphic - it'll work for any type emitted by
fifo1.deq(), assuming fifo2.enq() accepts the same type.

Bluespec is perhaps the opposite of high level synthesis:  it's good at
controlling how data is moved around.  C-to-gates HLS focuses on the
compute, without considering how data is communicated.  But the
communication in more-than-trivial C programs tends to be complex - using
the stack, heap and so on, maybe also threading.

You can't just build a C program with HLS and expect it to use your BRAMs
and your DDR3 as easily as C airily assumes the uniform flat address space
of the PDP-11.  On a CPU, caches and memory controllers hide that from
you.  In hardware they don't.

That's not to mention that a C representation takes an algorithm which might
have lots of parallelism and squeezes it down into a serialised form, and
then we expect HLS to re-extract all this parallelism?  Compilers are not
magic.

HLS tackles writing the algorithms which I view as the easy bit, while I
think moving the data around is the hard problem it just ignores.

Theo

(I did run the example code through the Bluespec compiler, but it just
output verilog of '% 24' - it views optimising that as the vendor tools'
job.  Which it's probably right about)

Article: 159072
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Devas <geve115@gmail.com>
Date: Mon, 25 Jul 2016 05:38:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Monday, July 25, 2016 at 12:38:58 PM UTC+2, Allan Herriman wrote:
> On Sun, 24 Jul 2016 23:48:46 -0700, Devas wrote:
> 
> > On Saturday, July 23, 2016 at 6:00:03 AM UTC+2, rickman wrote:
> >> On 7/22/2016 11:35 PM, Allan Herriman wrote:
> >> > On Fri, 22 Jul 2016 09:43:24 -0700, Kevin Neilson wrote:
> >> >
> >> >> It's 2016 and I still have to write out most of my code at very low
> >> > levels of abstraction like I did ten years ago.  Whenever I hear
> >> > about a new tool that supposedly converts C to gates, I don't even
> >> > look into it, because I can't even get Verilog to synth properly.
> >> >>
> >> >> My latest example:  I needed to reduce an 12-bit number, mod-24.
> >> >>
> >> >> input [11:0] x;
> >> >> always@(posedge clk) xmod24 <= x%24;
> >> >>
> >> >> When I put this in Vivado, what do I get?  40 LUTs (plus some carry
> >> > chains) and 10 levels of logic.  TEN.  Needless to say, that won't
> >> > meet timing at 350MHz, especially when it involves getting on and off
> >> > a bunch of little carry chains.
> >> >>
> >> >> So then I have to go down a level of abstraction:
> >> >>
> >> >> input [11:0];
> >> >> // x%24 = 8*(floor(x/8)%3) + x%8 always@(posedge clk)
> >> >>   xmod24 <= {x[11:3]%3, x[2:0]};
> >> >>
> >> >> Now I get 4 LUTs and TWO levels of logic.  TWO.  At least I didn't
> >> >> have
> >> > to instantiate primitives, like I still often do, even though it's
> >> > 2016.
> >> >>
> >> >> Needless to say, I am not about to waste a bunch of time trying out
> >> >> any
> >> > new "high-level synthesis" tools.
> >> >
> >> >
> >> > I find it easy to ignore HLS, but I still suffer from it because it
> >> > splits the tool vendors' development budget across multiple tools.
> >> >
> >> >
> >> > I got all excited when I first heard about high level synthesis. 
> >> > Then I discovered that the language was C - hardly high level, and
> >> > not particularly well suited to the sorts of things that FPGA coders
> >> > need to do.
> >> > It's not about making a better language though - it's about allowing
> >> > non-
> >> > FPGA people to do FPGA things, all in the name of market share.
> >> 
> >> I wouldn't say that.  I know when I have heard using C for synthesis
> >> discussed it is more about being able to write the entire project in C
> >> and pick multiple options for the hardware vs. software trade off.  I
> >> have no idea how realistic this might be.  But I don't think it is
> >> about suddenly having a vast pool of talent to design hardware.
> >> 
> >> --
> >> 
> >> Rick C
> > 
> > I attended a Xilinx meeting a couple of weeks ago. They told us that the
> > new tools (e.g SDSoc) are created for a new pool of engineers, e.g
> > software engineers, architects, etc. So this new pool of engineers is
> > also able to design FPGAs. They showed a "nice" slide with a very small
> > pool of FPGA engineers and a very big pool of software engineers.
> 
> 
> Yay, Xilinx development money spent on another tool I'll never use.
> 
> 
> In the meantime, I'm using ISE for my Virtex 6 designs (which I have to  
> support until 2020-something).  Xilinx hasn't updated ISE since 2013.  ISE 
> will never support the current versions of VHDL or Verilog.  Its bugs 
> will never be fixed.
> 
> 
> I'm sure this makes sense to the people in marketing.
> 
> Allan

It is all money. More engineers and companies designing FPGAs, more money for Xilinx, and who cares that the high level synthesis tool does not create the optimal code. How more LUTs are used (by HLS) how more money for Xilinx ;)

The same with VHDL 2008, SystemVerilog is more money than VHDL 2008. And it is your problem that ISE will not be updated even your device is not supported by Vivado :(

Article: 159073
Subject: Re: Xilinx Platform cable USB and impact on linux without windrvr
From: adityaishwar1994@gmail.com
Date: Mon, 25 Jul 2016 11:03:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
Getting following error at make step:

adityapappu@adityapappu-NV55C:/opt/Xilinx/usb-driver$ make
cc -Wall -fPIC -DUSB_DRIVER_VERSION=3D"\"2016-07-23 20:34:57\""  usb-driver=
.c xpcu.c parport.c config.c jtagmon.c -o libusb-driver.so -ldl -lusb -lpth=
read -shared
parport.c: In function =E2=80=98parport_transfer=E2=80=99:
parport.c:21:23: warning: variable =E2=80=98last_pp_write=E2=80=99 set but =
not used [-Wunused-but-set-variable]
  static unsigned char last_pp_write =3D 0;
                       ^
/usr/bin/ld: cannot open output file libusb-driver.so: Permission denied
collect2: error: ld returned 1 exit status
Makefile:28: recipe for target 'libusb-driver.so' failed
make: *** [libusb-driver.so] Error 1
adityapappu@adityapappu-NV55C:/opt/Xilinx/usb-driver$=20

Article: 159074
Subject: Re: Mod-24: The State of High-Level Synthesis in 2016
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Tue, 26 Jul 2016 10:30:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
They did claim that software engineers with no hardware experience could be designing FPGAs after a very short training period.  Which might have been true.  But there's a difference between doing FPGAs and doing them well.



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search