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 6/16/2016 1:57 PM, Jecel wrote: > On Wednesday, June 15, 2016 at 7:14:06 PM UTC-3, Rickman wrote: >> On 6/15/2016 5:43 PM, Jecel wrote: >>> "the same command line" might be the key to our differences. In the >>> native C64 Basic command line I can type something like >>> >>> PRINT (MADD/4)+1 >>> >>> and see the result. In a cross compiling Basic I can't do that. >> >> There's the problem. I'm using Forth. I didn't know we were talking >> about BASIC. > > :-) > > So we type > > MADD @ 4 / 1 + . > > instead. The point is that I don't have to first put that expression > in a colon definition, compile it, and then send it to the target > board to see the result. > >>> The J1 can't address much memory, so a native Forth is possible but would >>> be a tight fit. >> >> I don't recall the limitation, but I would expect it to be on the order >> of many KB. > > Let me check: > > http://excamera.com/files/j1.pdf > > "All target addresses - for call, jump and conditional branch > - are 13-bit. This limits code size to 8K words, or 16K bytes." > > Data uses 15 bit byte addresses, but the top half of the memory > map is reserved for I/O. So was have 16KB in all to play with. > >> Mecrisp is not so large and in fact, I'm pretty sure it has >> been ported to the J1. I seem to recall this was done using an open >> source package (the only one I've ever heard of) that compiles to a bit >> stream. In a fit of enthusiasm I believe Matthias Koch ported his Forth >> to this target making the entire effort open source. I can't recall for >> sure, but I'm pretty sure the hardware is also open source. > > Ok, so the answer to the original question is "yes"? Good. I've had some > nice machines (Mac, Sun Utra 5+, XO-1 from One Laptop Per Child) with > OpenFirmware (OpenBoot, as Sun called it) and it is a nice token threaded > Forth that can be used interactively. Not only is token threading > really compact, but it can also be used on Harvard architecture chips > like the Atmel AVR8. > >>> You mentioned a lack of mass storage on the target device, but these days >>> you can easily have 64Kb of Flash or more. >> >> 64 kB of on target flash is not of much value for storing source. You >> have virtually no tools for printing, copying, backup, etc. I use a PC >> for all that. > > Normally, I would agree. But for Forth or Basic (as in BasicStamp boards) > it might be enough. Most early microcomputers had 80KB floppy disks. I have no idea what you are trying to say with this. Lots of things were done in the early days of programming including using toggle switches to enter programs. I don't wish to duplicate any of that. >>> In any case, my own SiliconSqueak is way larger than the J1 and is meant >>> for boards with more resources, though not necessarily as large as a >>> Raspberry Pi. >> >> You mean an FPGA board? The rPi has a higher end ARM processor. > > The R-Pi also has SDRAM, HDMI output, USBs and Ethernet which is also > the case for some FPGA boards. And those with chips like Zynq have > FPGAs and ARMs. > > What I was saying was that I am also interested in FPGA boards with not > as much memory and with poorer I/O (VGA and PS/2, for example) than > the Pi. I don't know what you are trying to say here. You mentioned your "SiliconSqueak" which I assume is a processor design. You seem to be talking about running it on an rPi which doesn't make sense. Were you just using the rPi as a point of comparison? -- Rick CArticle: 159026
I am working with Active HDL and I'm pretty sure in the past I was able to set generics at the top level from within the simulator. I see in the Design, Settings dialog box they have a Simulation, Generic/Parameters choice which looks like it should display design generics, but I can't see them. The help file talks about editing these items, but I see no editing controls either. Anyone know what I'm doing wrong? -- Rick CArticle: 159027
Jecel wrote: [snip] > > What I was saying was that I am also interested in FPGA boards with not > as much memory and with poorer I/O (VGA and PS/2, for example) than > the Pi. > > -- Jecel Many low-end FPGA boards are out there, but in general the peripherals are richer on the boards with a larger FPGA. For a bare-bones starter board with VGA and USB and PMOD, you could look at: https://www.nandland.com/goboard/introduction.html However the ICE40 on that board is not very large for playing with embedded processors. If you can live with HDMI instead of VGA, then possibly the Scarab MiniSpartan6+ would be a possibility. Just be aware that the SDRAM on that board is single-data-rate and won't work with the built-in hard memory control block of the Spartan-6. https://www.scarabhardware.com/minispartan6/ -- GaborArticle: 159028
I don't have any trouble getting the simulation (Active HDL) or synthesis (Synplify) tools to work with VHDL-2008, but the Lattice tool itself doesn't seem to understand it. When Diamond analyzes the source files it complains of syntax errors. The rest of the tool seems to work just fine and this doesn't stop me from completing the project. I did an Internet search and found a post at eevblog.com about this from last year with no response. I put in a ticket to Lattice. I am using a slightly old version of the tool, 3.3 while the latest is 3.7 I believe. I hope that's not my problem. lol -- Rick CArticle: 159029
On 16/06/2016 22:39, GaborSzakacs wrote: > Jecel wrote: > > [snip] > >> >> What I was saying was that I am also interested in FPGA boards with not >> as much memory and with poorer I/O (VGA and PS/2, for example) than >> the Pi. >> >> -- Jecel > > Many low-end FPGA boards are out there, but in general the peripherals > are richer on the boards with a larger FPGA. For a bare-bones starter > board with VGA and USB and PMOD, you could look at: > > https://www.nandland.com/goboard/introduction.html > > However the ICE40 on that board is not very large for playing with > embedded processors. > > If you can live with HDMI instead of VGA, then possibly the Scarab > MiniSpartan6+ would be a possibility. Just be aware that the > SDRAM on that board is single-data-rate and won't work with the > built-in hard memory control block of the Spartan-6. > > https://www.scarabhardware.com/minispartan6/ > I have used one of these http://www.ebay.com/itm/251192875961 for a very small system Dave G4UGMArticle: 159030
Rickman, > > Normally, I would agree. But for Forth or Basic (as in BasicStamp boards) > > it might be enough. Most early microcomputers had 80KB floppy disks. > > I have no idea what you are trying to say with this. Lots of things > were done in the early days of programming including using toggle > switches to enter programs. I don't wish to duplicate any of that. I am saying some programming environments are pretty small and some embedded processors are getting large enough that the two can meet. Sure, small can mean primitive and awkward but not necessarily. I find stuff build around Eclipse pretty unusable so consider the GB of disk and RAM that they need a waste. > I don't know what you are trying to say here. You mentioned your > "SiliconSqueak" which I assume is a processor design. You seem to be > talking about running it on an rPi which doesn't make sense. Were you > just using the rPi as a point of comparison? Sorry about the confusion. SiliconSqueak is indeed my own processor and I was talking about implementing it on low end FPGA boards (Gabor and Dave Wade have just suggested some nice options in this thread) and comparing their resources with those available on the Raspberry Pi. The Squeak virtual machine (both the original interpreter and the new Cog JIT compiler) runs very well on the Raspberry Pi thanks to the foundation's efforts to make Scratch more usable. This means you can either run some software on the Pi with these VMs or on an FPGA board with my processor. That makes comparing the two options interesting, though an FPGA board costing around $100 might have less resources than a Pi board costing $5. -- JecelArticle: 159031
On 5/13/2011 7:34 AM, wzab wrote: > Hi, > > I'm very impressed with a J1 forth processor: http://excamera.com/sphinx/fpga-j1.html > I'd like to use it to implement simple non-time critical control and > debugging layer > in my FPGA based DSP system. > However to accomplish it I need to add possibility of interactive work > via console > connected either by UART or by JTAG. > Has anybody tried to extend the J1 published in http://excamera.com/files/j1demo.tar.gz > with possibility to interactively define new words and execute them? > -- > TIA & Regards, > WZab > Its king of a round way to what you want, but the following is interesting and might accomplish what you wish. The ep16 CPU contains within it's zip file the following; weForth - a Windows version of eForth used to create a development system. Meta compiler - for the ep16 but easily modified for other stack machines eForth source - not in assembler but in Forth primitives be meta-compile into the target CPU Documentation - not just for the CPU, and more importantly for the software. This package will result in a copy of eForth that would be resident in the target CPU I am working with the ep32 which comes with the same software to learn VHDL, my next target is the ep16, followed by the J1, when I get there I will be modifying the target compiler to generate J1 primitives and in so doing ending with a copy of eForth that resides inside the J1. You can wait until I get there or you can Download the code for the ep16 and modify it yourself. Theoretically the J1 has many new instructions built in without changing the FPGA code, you would have to add the extra instructions that are already there but nor used to the metacompiler software, it looks like it's a relatively simple task. Have fun going Forth. -- Cecil - k5nwaArticle: 159032
On 6/17/2016 1:37 PM, Jecel wrote: > Rickman, > >>> Normally, I would agree. But for Forth or Basic (as in BasicStamp boards) >>> it might be enough. Most early microcomputers had 80KB floppy disks. >> >> I have no idea what you are trying to say with this. Lots of things >> were done in the early days of programming including using toggle >> switches to enter programs. I don't wish to duplicate any of that. > > I am saying some programming environments are pretty small and some embedded > processors are getting large enough that the two can meet. Sure, small can > mean primitive and awkward but not necessarily. I find stuff build around > Eclipse pretty unusable so consider the GB of disk and RAM that they need > a waste. I have no idea why you are bringing Eclipse into a Forth discussion. Programming from a PC is the easiest way to work unless your target is heavy enough to support an operating system. So in the Raspberry Pi I program directly on the target. Any embedded board, even with an on board Forth compiler, the PC gets used as the host for most development work while debugging is on the target. I load the code which is one command and takes maybe a second. I test a few words or word from the command line until I find a bug and make changes. I forget the stuff just loaded, load the new code and in less than 5 seconds I'm back to debugging. Hardly an onerous cycle. In fact, I barely know I'm working from my laptop on a remote target until I get the target locked up and have to walk to the other room to push the reset. >> I don't know what you are trying to say here. You mentioned your >> "SiliconSqueak" which I assume is a processor design. You seem to be >> talking about running it on an rPi which doesn't make sense. Were you >> just using the rPi as a point of comparison? > > Sorry about the confusion. SiliconSqueak is indeed my own processor and > I was talking about implementing it on low end FPGA boards (Gabor and > Dave Wade have just suggested some nice options in this thread) and > comparing their resources with those available on the Raspberry Pi. I haven't spent much time looking at FPGA boards. I build products with FPGA but they are seldom on boards that would support other than fairly primitive processors that are doing simple control functions. My current product does not have a processor, but the FPGA is maxed out. The FPGA is also obsolete and eventually the board will need to be redesigned. When this happens the code will need to be ported and some of the slow speed stuff might be better in a soft CPU. > The Squeak virtual machine (both the original interpreter and the new > Cog JIT compiler) runs very well on the Raspberry Pi thanks to the > foundation's efforts to make Scratch more usable. This means you can > either run some software on the Pi with these VMs or on an FPGA board > with my processor. That makes comparing the two options interesting, > though an FPGA board costing around $100 might have less resources > than a Pi board costing $5. If I thought anyone was interested and could find a software guy to team up with, I would produce an FPGA board which connected to the fast interfaces on a CPU like the rPi or maybe a BeagleBone and use the resources on the processor board as a low cost I/O processor for the FPGA. That reminds me of the array processor I used to work on that had a compute head on one board and the entire rest of the two rack cabinets (including two 68010 processors) were support to get data in and out of the compute head. -- Rick CArticle: 159033
On 6/16/2016 4:35 PM, rickman wrote: > I am working with Active HDL and I'm pretty sure in the past I was able > to set generics at the top level from within the simulator. I see in > the Design, Settings dialog box they have a Simulation, > Generic/Parameters choice which looks like it should display design > generics, but I can't see them. The help file talks about editing these > items, but I see no editing controls either. > > Anyone know what I'm doing wrong? > Not a clue, I'm about to install MyDHL on a virtual Windows 7 PC that is used to work with FPGAs, it's the final piece of software before I declare the image finished, I will have one with Lattice Diamond, and a second one with Xilinx Vivado. I wish that Lattice had more powerful inexpensive board, but they go from $43 for the Brevia2 to very expensive boards, It would be nice to just have one development system. -- Cecil - k5nwaArticle: 159034
Rick, sorry that I am not addressing the rest of your post, but I think we have both said all there is to be said about the subject and won't reach an agreement. > If I thought anyone was interested and could find a software guy to team > up with, I would produce an FPGA board which connected to the fast > interfaces on a CPU like the rPi or maybe a BeagleBone and use the > resources on the processor board as a low cost I/O processor for the > FPGA. That reminds me of the array processor I used to work on that had > a compute head on one board and the entire rest of the two rack cabinets > (including two 68010 processors) were support to get data in and out of > the compute head. While perhaps not using the fast interfaces, there are FPGA expansions for the boards you mentioned: http://www.bugblat.com/products/pif/ http://valentfx.com/logi-pi/ http://valentfx.com/logi-bone/ The way to have the fastest possible interface between the FPGA and the processor is to use a chip like the Xilinx Zynq, which includes two ARM cores. There are many variations of the Zed board with this chip: http://zedboard.org/ The one most like what you were describing is probably the Parallella board, which is essentially a Zed board in a Raspberry Pi form factor plus an Epiphany chip with 16 (or 64) floating pointer processors: https://www.parallella.org/ -- JecelArticle: 159035
On 6/18/2016 3:44 PM, Cecil Bayona wrote: > On 6/16/2016 4:35 PM, rickman wrote: >> I am working with Active HDL and I'm pretty sure in the past I was able >> to set generics at the top level from within the simulator. I see in >> the Design, Settings dialog box they have a Simulation, >> Generic/Parameters choice which looks like it should display design >> generics, but I can't see them. The help file talks about editing these >> items, but I see no editing controls either. >> >> Anyone know what I'm doing wrong? >> > Not a clue, I'm about to install MyDHL on a virtual Windows 7 PC that is > used to work with FPGAs, it's the final piece of software before I > declare the image finished, I will have one with Lattice Diamond, and a > second one with Xilinx Vivado. > > I wish that Lattice had more powerful inexpensive board, but they go > from $43 for the Brevia2 to very expensive boards, It would be nice to > just have one development system. What would you like to see on the board? -- Rick CArticle: 159036
On 6/18/2016 8:41 PM, rickman wrote: > On 6/18/2016 3:44 PM, Cecil Bayona wrote: >> On 6/16/2016 4:35 PM, rickman wrote: >>> I am working with Active HDL and I'm pretty sure in the past I was able >>> to set generics at the top level from within the simulator. I see in >>> the Design, Settings dialog box they have a Simulation, >>> Generic/Parameters choice which looks like it should display design >>> generics, but I can't see them. The help file talks about editing these >>> items, but I see no editing controls either. >>> >>> Anyone know what I'm doing wrong? >>> >> Not a clue, I'm about to install MyDHL on a virtual Windows 7 PC that is >> used to work with FPGAs, it's the final piece of software before I >> declare the image finished, I will have one with Lattice Diamond, and a >> second one with Xilinx Vivado. >> >> I wish that Lattice had more powerful inexpensive board, but they go >> from $43 for the Brevia2 to very expensive boards, It would be nice to >> just have one development system. > > What would you like to see on the board? > A little bigger FPGA, the current one is the smallest in the family so it can have more internal RAM and in some CPUs more LUTs doesn't hurt, 32 bit wide fast external static RAM. Mind you, the Brevia2 you is a very nice board for $43, the device has a few DSP slices, instant on, built in hard devices, SIO, I2C, and a timer/PWM device, 128KB of 8 bit wide external SRAM, you can implement simple and not so simple Stack based CPUs, but the built in RAM is kind of thin, and the external RAM is only 8 bits wide so it makes things messy if you need more RAM. You can get some nice deals from China but they are Xilinx or Altera boards, I was looking and there are some nice and fast RAM chips that are 16 wide, two of them and you have 32 bit SRAM, so later a plug in board might be handy, and might be something I could sell. But right now I have too many things going on to tackle that project. There is one good deal from Xilinx that you don't have to buy from China, the Arty, using the Artix7 chip, 20K LUTs so it can handle more complex projects, 240KB of internal RAM, and 256MB of 16 bit wide DDR3 RAM, 450MHz internal speed for $99 -- Cecil - k5nwaArticle: 159037
On 6/18/2016 11:13 PM, Cecil Bayona wrote: > On 6/18/2016 8:41 PM, rickman wrote: >> On 6/18/2016 3:44 PM, Cecil Bayona wrote: >>> On 6/16/2016 4:35 PM, rickman wrote: >>>> I am working with Active HDL and I'm pretty sure in the past I was able >>>> to set generics at the top level from within the simulator. I see in >>>> the Design, Settings dialog box they have a Simulation, >>>> Generic/Parameters choice which looks like it should display design >>>> generics, but I can't see them. The help file talks about editing >>>> these >>>> items, but I see no editing controls either. >>>> >>>> Anyone know what I'm doing wrong? >>>> >>> Not a clue, I'm about to install MyDHL on a virtual Windows 7 PC that is >>> used to work with FPGAs, it's the final piece of software before I >>> declare the image finished, I will have one with Lattice Diamond, and a >>> second one with Xilinx Vivado. >>> >>> I wish that Lattice had more powerful inexpensive board, but they go >>> from $43 for the Brevia2 to very expensive boards, It would be nice to >>> just have one development system. >> >> What would you like to see on the board? >> > A little bigger FPGA, the current one is the smallest in the family so > it can have more internal RAM and in some CPUs more LUTs doesn't hurt, > 32 bit wide fast external static RAM. > > Mind you, the Brevia2 you is a very nice board for $43, the device has a > few DSP slices, instant on, built in hard devices, SIO, I2C, and a > timer/PWM device, 128KB of 8 bit wide external SRAM, you can implement > simple and not so simple Stack based CPUs, but the built in RAM is kind > of thin, and the external RAM is only 8 bits wide so it makes things > messy if you need more RAM. > > You can get some nice deals from China but they are Xilinx or Altera > boards, I was looking and there are some nice and fast RAM chips that > are 16 wide, two of them and you have 32 bit SRAM, so later a plug in > board might be handy, and might be something I could sell. But right now > I have too many things going on to tackle that project. There is one > good deal from Xilinx that you don't have to buy from China, the Arty, > using the Artix7 chip, 20K LUTs so it can handle more complex projects, > 240KB of internal RAM, and 256MB of 16 bit wide DDR3 RAM, 450MHz > internal speed for $99 I'm not clear on your response. The only thing you would like to see is a larger FPGA and faster, wider RAM? -- Rick CArticle: 159038
On 6/18/2016 10:25 PM, rickman wrote: > On 6/18/2016 11:13 PM, Cecil Bayona wrote: >> On 6/18/2016 8:41 PM, rickman wrote: >>> On 6/18/2016 3:44 PM, Cecil Bayona wrote: >>>> On 6/16/2016 4:35 PM, rickman wrote: >>>>> I am working with Active HDL and I'm pretty sure in the past I was >>>>> able >>>>> to set generics at the top level from within the simulator. I see in >>>>> the Design, Settings dialog box they have a Simulation, >>>>> Generic/Parameters choice which looks like it should display design >>>>> generics, but I can't see them. The help file talks about editing >>>>> these >>>>> items, but I see no editing controls either. >>>>> >>>>> Anyone know what I'm doing wrong? >>>>> >>>> Not a clue, I'm about to install MyDHL on a virtual Windows 7 PC >>>> that is >>>> used to work with FPGAs, it's the final piece of software before I >>>> declare the image finished, I will have one with Lattice Diamond, and a >>>> second one with Xilinx Vivado. >>>> >>>> I wish that Lattice had more powerful inexpensive board, but they go >>>> from $43 for the Brevia2 to very expensive boards, It would be nice to >>>> just have one development system. >>> >>> What would you like to see on the board? >>> >> A little bigger FPGA, the current one is the smallest in the family so >> it can have more internal RAM and in some CPUs more LUTs doesn't hurt, >> 32 bit wide fast external static RAM. >> >> Mind you, the Brevia2 you is a very nice board for $43, the device has a >> few DSP slices, instant on, built in hard devices, SIO, I2C, and a >> timer/PWM device, 128KB of 8 bit wide external SRAM, you can implement >> simple and not so simple Stack based CPUs, but the built in RAM is kind >> of thin, and the external RAM is only 8 bits wide so it makes things >> messy if you need more RAM. >> >> You can get some nice deals from China but they are Xilinx or Altera >> boards, I was looking and there are some nice and fast RAM chips that >> are 16 wide, two of them and you have 32 bit SRAM, so later a plug in >> board might be handy, and might be something I could sell. But right now >> I have too many things going on to tackle that project. There is one >> good deal from Xilinx that you don't have to buy from China, the Arty, >> using the Artix7 chip, 20K LUTs so it can handle more complex projects, >> 240KB of internal RAM, and 256MB of 16 bit wide DDR3 RAM, 450MHz >> internal speed for $99 > > I'm not clear on your response. The only thing you would like to see is > a larger FPGA and faster, wider RAM? > Yes, although the Brevia2 is not slow, but 32bit fast SRAM and a larger FPGA version of it would be great if available for a reasonable price. Now in case the "Wish Fairy" is listening I would not mind a brand new Forrester, and a 50" 4K monitor. -- Cecil - k5nwaArticle: 159039
>> The J1 can't address much memory, so a native Forth is possible but would >> be a tight fit. > > I don't recall the limitation, but I would expect it to be on the order > of many KB. Mecrisp is not so large and in fact, I'm pretty sure it has > been ported to the J1. I seem to recall this was done using an open > source package (the only one I've ever heard of) that compiles to a bit > stream. In a fit of enthusiasm I believe Matthias Koch ported his Forth > to this target making the entire effort open source. I can't recall for > sure, but I'm pretty sure the hardware is also open source. Exactly, Swapforth by James Bowman and my descendant Mecrisp-Ice with optimisations run happily in HX1K FPGAs, Icestick and Nandland Go are supported. If you wish to add more opcodes to the CPU or need gates for something else, you should go for the HX8K breakout board instead. MatthiasArticle: 159040
On 5/13/2011 7:34 AM, wzab wrote: > Hi, > > I'm very impressed with a J1 forth processor: http://excamera.com/sphinx/fpga-j1.html > I'd like to use it to implement simple non-time critical control and > debugging layer > in my FPGA based DSP system. > However to accomplish it I need to add possibility of interactive work > via console > connected either by UART or by JTAG. > Has anybody tried to extend the J1 published in http://excamera.com/files/j1demo.tar.gz > with possibility to interactively define new words and execute them? > -- > TIA & Regards, > WZab > I have the ep8080, the ep16, and ep32 cores now working along with a resident version of eForth in each of those CPUs, the next CPU will be the J1 but first I will need to take a slight detour. I will continue working on the ep32 core for a while as a learning vehicle to learn VHDL, so after some minor upgrades such as adding an additional address register, and additional instructions, when I feel comfortable with VHDL I will proceed to the J1 CPU. The first step will be to create a J1 Meta-compiler so I can create a J1 version of eForth that resides in the J1 CPU. If by then you do not have a resident Forth compiler you might be interested in the J1 native version of eForth. Once that is working with the existing J1 CPU Verilog code, I will proceed to create a version of the J1 in VHDL. If you are interested let me know and I can do the above in a slightly different order, but no matter what I will need to learn VHDL first as the J1 is written in Verilog for a different FPGA than the ones I have so. Maybe all the above is not necessary as there is a native eForth implementation available that I just found. Along with it is code to implement a serial port so the J1 can talk to the outside world. < https://github.com/samawati/j1eforth > -- Cecil - k5nwaArticle: 159041
Not sure what to make of this problem, I am having IPexpress in Lattice Diamond generate a corrupted file if I define a RAM module for use with a soft CPU. I have a copy of the original generated file, but when I try to generate myself following the documentation, the file generated differs from the original by two words in the area of loading data into the RAM. I have three soft CPUs that I have used IPexpress to generate the RAM module, and only one project has the problem, a project to create the ep16 soft CPU. I tried after verifying in the manual that I had the right parameters when using IPexpress to create a new ram_memory.vhd file, below are some observations and steps taken to try to fix the problem; 1. The problem occurs only with the ep16 processor project. 2. From the latest version of Diamond 3.7.1 to version 1.4 and every version in between, they all have the same problem, there is a two word difference in the code between the original ram_memory.vhd file and the newly generated file. If those two words are not corrected, the loaded eForth software crashes. 3. The original ep16BIN.mem (binary image of the software), and a newly created copy are identical, so that is not the problem. 4. I looked on how one defines the ep16BIN.mem file and the method seems correct, the only difference I saw was the ep16BIN.mem file generated for the ep16 says that memory entries are 32 bits which is not correct, it should be 16 bits, but even after changing it, it still creates a ram_memory.vhd file with two wrong words. 5. The problem does not show up on the ep32, or PDP1 projects, it only has a problem on the ep16 project. 6. I went and created two new ep16 projects from scratch and the same thing happens. 7. I tried running the Lattice software in Windows 10, and Windows 7 and there is no difference. 8 If one uses the original ram_memory.vhd or a newly generated version with the two words corrections then all versions of Diamond create a working project, in both cases I use the same binary image of the software. I'm going to have to think about this as I'm out of ideas at the present, If you have any ideas they would be welcomed. I do need to figure out what is going on because I want to make changes to the ep16, ep32, and eventually work on the J1 CPU which involve making changes to the RAM module and I need to have reliable ram_memory.vhd file generated as I wont have anything to compare it to. Thanks for putting up with a long post. -- Cecil - k5nwaArticle: 159042
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! Cheerio! Kr. BonneArticle: 159043
kristoff <kristoff@skypro.be> writes: > Can somebody give a little more information what exactly I need for > this? Exactly what file do I need to create? From memory (since I haven't done this in a while) you need a .jic file and you create that from your .sof file in the "convert programming files" dialog. You need to specify the flash type as well and as I recall, the UI isn't very intuitive. I think I have a script somewhere which does it on the command line, easier to share on Usenet...Article: 159044
On 05/07/2016 23:03, 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! > > > > Cheerio! Kr. Bonne > You need to attach a serial flash loader to your design, this interfaces the jtag socket to your flash device. In the serial flash loader megawizard do not tick Share ASMI interface or Use enhanced mode SFL boxes. Connect the noe_in pin on the instatiated loader to vcc (this should be the only pin. To program the device you need to generate a *.jlc file using the quartus file convertor. Hope that helps AndyArticle: 159045
Andy, Anssi, On 06-07-16 10:08, Andy Bennet wrote: >> Can somebody explain how exactly to program this device so that the >> configuration is stored inthe serial flash device? (...) > You need to attach a serial flash loader to your design, this interfaces > the jtag socket to your flash device. In the serial flash loader > megawizard do not tick Share ASMI interface or Use enhanced mode SFL > boxes. Connect the noe_in pin on the instatiated loader to vcc (this > should be the only pin. > To program the device you need to generate a *.jlc file using the > quartus file convertor. Both thanks for replying. It really helps to know at least what file you need to create :-) to sum it all up (for the archive of this NG, if somebody else might have the same issue). I managed to do it like this: - synthesis the VHDL design -> this creates a .sof file in the "output_files" directory - file -> convert programming files programming-type = .jic configuration-device = (in my case) epcs16 input-files: flash-loader -> click on "add device" -> select your fpga (in my case) ep4ce10 sof data -> click on "add file" -> select your .sof file click on "generate" and then "close" - go to the programmer: choice "add file" -> select the .jic file Then program as normal. Pff! (I think I'll just program it in memory. That is a lot faster!). > Hope that helps It sure did. Thanks! > Andy Cheerio! Kr. Bonne.Article: 159046
On 6/16/2016 11:23 PM, rickman wrote: > I don't have any trouble getting the simulation (Active HDL) or > synthesis (Synplify) tools to work with VHDL-2008, but the Lattice tool > itself doesn't seem to understand it. When Diamond analyzes the source > files it complains of syntax errors. The rest of the tool seems to work > just fine and this doesn't stop me from completing the project. > > I did an Internet search and found a post at eevblog.com about this from > last year with no response. I put in a ticket to Lattice. I am using a > slightly old version of the tool, 3.3 while the latest is 3.7 I believe. > I hope that's not my problem. lol Wow! This has been dragging out for a bit. They replied saying the LSE tool can be set for VHDL-2008. I wrote back that I don't have a setting for LSE. They sent me a screen shot showing the setting in a dialog box. I sent back a screen shot showing the same dialog box in my tool that doesn't have the LSE setting. I've downloaded the most recent version of the tools and installed them before doing this. Regardless, I'm not sure that LSE is the right setting. That's an alternative synthesis tool, right, "Lattice Synthesis Engine"? Is that what they use to parse the source when the design is "refreshed"? 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. -- Rick CArticle: 159047
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. -- GaborArticle: 159048
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...Article: 159049
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
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