Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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 CArticle: 159051
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
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 McCArticle: 159053
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. -- GaborArticle: 159054
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 CArticle: 159055
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 CArticle: 159056
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 CArticle: 159057
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 CArticle: 159058
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
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 CArticle: 159060
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 CArticle: 159061
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
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
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
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: 159065I 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
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
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 CArticle: 159068
What about SDSoC Development Environment? Anyone with some hands on experience? I've seen a demo a few moths back and that looked promissingArticle: 159069
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
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: 159071Emilian 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
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
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: 159074They 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:
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