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
Hi, Can anyone provide me with a board support package for the ML405 board? In EDK 8.1 installation only ML401/402/403/410 are supported. I can not find it on Xilinx site Thanks, gerdArticle: 112176
Antti Lukats wrote: > Jim Granville" <no.spam@designtools.maps.co.nz> schrieb im Newsbeitrag > news:455cf081$1@clear.net.nz... > > learnfpga wrote: > >> I am new to CPLD's and I am trying to make a new design incorporating > >> some of the old abel code. I am using schematic entry (XC9572). I have > >> converted the abel code into symbols and incorporating them to my > >> schematic. In the new design I am not using many of the input and > >> outputs that were defined in the abel code but I dont want to fiddle > >> with that and so I am using the code as it is. > >> > >> Now when I synthesize I get following warnings.. > >> > >> WARNING:Xst:647 - Input <A00> is never used. > >> > >> WARNING:Xst:646 - Signal <CARRY_12> is assigned but never used. > >> > >> WARNING:Xst:2170 - Unit PN67c : the following signal(s) form a > >> combinatorial loop: _xor0004, BEL, _xor0002 > >> > >> WARNING:Xst:1354 - Port SPAREI is not connected, attached property > >> removed (LOC) > >> > >> > >> Should I worry about these warnings because I am not using all these > >> ports/signals/input? > >> > >> At present I have connected all unused inputs to ground and left the > >> unused outputs as it is. Is that the right approach? > >> > >> Thanks for any responses... > > > > Check the fitter report files, they will show you what _actually_ > > happened. > > > > Why design in schematic, if you already have the code in abel ?. > > AFAIK Xilinx still supports that flow fine for CPLDs. Thanks for the response.... Because of the time constraint involved I am most comfortable with schematic instead of abel. > > > > -jg > > > > Jim > > this is a bug in ISE 8.x it only happens for 95xx CPLDs > IMHO the only solution is to use ISE 7.1 or 6.3 for XC95xx > I changed the CPLD to xc2c128 and XCR3128XL. I still got the same warnings as before.... Should I try using ISE7.1? Thanks > AnttiArticle: 112177
Hi to everyone, I'm developing some electronics to make a time measurement with a resolution of 25 ps. I'm using a dedicated ASIC to do so but I'm giving the signals to the ASIC through an FPGA. The way is very simple, basically I have some signals coming to my fpga which I will mask with some combinatorial logic and a configurable register so that I can allow some measurements or some others. The output of this "masking" will go to the ASIC. They assert (and here is the question) that a clocked device as an FPGA may add some jitter to the signals due to the substrate current overload (for the presence of the clock) that will lead to some 15 ps jitter over the signals. I don't know how they could resolve this value but I'm assuming they were telling the truth about numbers (at least, while I have some doubts about explanation of those numbers). Can anyone say something about this? Does it sound reasonable? Al -- Alessandro Basili CERN, PH/UGC Hardware DesignerArticle: 112178
learnfpga schrieb: > Antti Lukats wrote: > > Jim Granville" <no.spam@designtools.maps.co.nz> schrieb im Newsbeitrag > > news:455cf081$1@clear.net.nz... > > > learnfpga wrote: > > >> I am new to CPLD's and I am trying to make a new design incorporating > > >> some of the old abel code. I am using schematic entry (XC9572). I have > > >> converted the abel code into symbols and incorporating them to my > > >> schematic. In the new design I am not using many of the input and > > >> outputs that were defined in the abel code but I dont want to fiddle > > >> with that and so I am using the code as it is. > > >> > > >> Now when I synthesize I get following warnings.. > > >> > > >> WARNING:Xst:647 - Input <A00> is never used. > > >> > > >> WARNING:Xst:646 - Signal <CARRY_12> is assigned but never used. > > >> > > >> WARNING:Xst:2170 - Unit PN67c : the following signal(s) form a > > >> combinatorial loop: _xor0004, BEL, _xor0002 > > >> > > >> WARNING:Xst:1354 - Port SPAREI is not connected, attached property > > >> removed (LOC) > > >> > > >> > > >> Should I worry about these warnings because I am not using all these > > >> ports/signals/input? > > >> > > >> At present I have connected all unused inputs to ground and left the > > >> unused outputs as it is. Is that the right approach? > > >> > > >> Thanks for any responses... > > > > > > Check the fitter report files, they will show you what _actually_ > > > happened. > > > > > > Why design in schematic, if you already have the code in abel ?. > > > AFAIK Xilinx still supports that flow fine for CPLDs. > > Thanks for the response.... > Because of the time constraint involved I am most comfortable with > schematic instead of abel. > > > > > > > -jg > > > > > > > Jim > > > > this is a bug in ISE 8.x it only happens for 95xx CPLDs > > IMHO the only solution is to use ISE 7.1 or 6.3 for XC95xx > > > > I changed the CPLD to xc2c128 and XCR3128XL. I still got the same > warnings as before.... > > Should I try using ISE7.1? Thanks well what I witnessed was single design 8.1 or 8.2 95xx target several input pins are 'left out' coolrunner/II or any FPGA target ALL OK 6.3 or 7.1 95xx all input pins remained ok so I assumed that only 95xx fitter has been broken in 8.x but maybe its even more global mess with 8.x CPLDs try 7.1 and open an webcase also AnttiArticle: 112179
Hi,
> I just cant belive it, its one of the most useful things for the FPGA
> SoC designs, and its just not there? I really doesnt have time or fun
> to reverse engineer the .SOF format only to be able write the data2sof
> utility for Altera.
I do, which chip do you intend to use ?
the sof is really easy to parse, it's a sequence of option number /
option length / option data:
typedef struct _bitstream_option {
uint16_t option; /* le */
uint32_t length; /* le */
char data[];
} PACKED bitstream_option_t;
The RAM data is the option code 19, IIRC. The only hard part is
figuring how to generate the CRC (option 8, seems like a CRC32,
but...).
JB
Article: 112180
Hi Antti,
Not sure if this helps but I use Altera's altsyncram memories in my design
which I pre-load using some generics
init_file => "..\cpu8088\nios_board\bootloader\mon86.hex"
then when the design is loaded I can change the memory contents on the fly
using the Quartus "In-System Memory contents editor". You do need to set
some more generics in advance to make this work:
lpm_hint => "ENABLE_RUNTIME_MOD=YES, INSTANCE_NAME=RA86",
Regards,
Hans
www.ht-lab.com
"Antti" <Antti.Lukats@xilant.com> wrote in message
news:1163775000.686739.11560@h48g2000cwc.googlegroups.com...
> Hi,
>
> Altera is promoting its own soft-core processor, but it seems that they
> have "forgotten" the one of the most important things out of their
> tool-flow, namly it seems to impossible to merge the FPGA tool
> generated files after the flow with memory init files, like it doable
> with Xilinx and Lattice FPGA's.
>
> I just cant belive it, its one of the most useful things for the FPGA
> SoC designs, and its just not there? I really doesnt have time or fun
> to reverse engineer the .SOF format only to be able write the data2sof
> utility for Altera.
>
> Antti
> PS I am almost impressed about the Quality of Quartus 6.0, it took over
> 2 hours before it trapped into internal error and self terminated. For
> ISE 8.2 this time was 20 minutes, so Altera is leading as of software
> tool quality. Hm, nops, I dont recall Lattice tools to have self
> termination effects.
>
Article: 112181Some of these warnings can be ignored, but some are potentially signficant problems. Unused inputs can be safely ignored. Assigned, but not used can be ignored if you are sure this is a signal that you intended to not use. A combinatorial loop may be an error or it may be intentional, but outside the normal usage of these devices. A combinatorial loop can be an intended latch or an unintended latch. You need to figure out which you have. The bottom line is that you should design to avoid warnings because otherwise you need to investigate each one to make sure it is not a real problem. By leaving them in you need to at least go through the list each time to make sure no new ones have been generated. learnfpga wrote: > I am new to CPLD's and I am trying to make a new design incorporating > some of the old abel code. I am using schematic entry (XC9572). I have > converted the abel code into symbols and incorporating them to my > schematic. In the new design I am not using many of the input and > outputs that were defined in the abel code but I dont want to fiddle > with that and so I am using the code as it is. > > Now when I synthesize I get following warnings.. > > WARNING:Xst:647 - Input <A00> is never used. > > WARNING:Xst:646 - Signal <CARRY_12> is assigned but never used. > > WARNING:Xst:2170 - Unit PN67c : the following signal(s) form a > combinatorial loop: _xor0004, BEL, _xor0002 > > WARNING:Xst:1354 - Port SPAREI is not connected, attached property > removed (LOC) > > > Should I worry about these warnings because I am not using all these > ports/signals/input? > > At present I have connected all unused inputs to ground and left the > unused outputs as it is. Is that the right approach? > > Thanks for any responses...Article: 112182
Al, Passing a signal through an FPGA, and then expecting to resolve 25 ps is not a good idea. The FPGA may add as much as thousands (yes thousands) of picoseconds of jitter: it all depends on the number of clocks running, their frequencies, if they are asynchronous or not, the number of CLB flip flops toggling (internal simultaneous switching), and the number of external IOs switching (SSO noise). Additionally, since jitter is caused by anything being less than perfect, this also includes the power distribution network, and the signal integrity of all the traces (rise times, fall times, reflections, etc.). The jitter floor for a FPGA that is doing nothing at all (signal in,, signal out) is probably around 35 picoseconds peak to peak. A completely synchronous design with everything done perfectly will probably come in at around 150 picoseconds, peak to peak jitter. An ASIC is probably the last thing I would choose to do jitter measurement. As I have said, you do anything wrong (at all), and you will fail. Jitter is the result of converting amplitude variations into phase variations. AM to PM is the bane of our existence: it can not be prevented, only minimized. Miss one contributor, and you fail to meet your specification (and delay your project by many months). To resolve the time you desire, it requires very high speed design (PECL), and virtually perfect power distribution, and signal integrity. I hope others here on the newsgroup will provide you with some better guidance, as all I have done is explained the problems. Austin Al wrote: > Hi to everyone, > I'm developing some electronics to make a time measurement with a > resolution of 25 ps. I'm using a dedicated ASIC to do so but I'm giving > the signals to the ASIC through an FPGA. > The way is very simple, basically I have some signals coming to my fpga > which I will mask with some combinatorial logic and a configurable > register so that I can allow some measurements or some others. The > output of this "masking" will go to the ASIC. > They assert (and here is the question) that a clocked device as an FPGA > may add some jitter to the signals due to the substrate current > overload (for the presence of the clock) that will lead to some 15 ps > jitter over the signals. I don't know how they could resolve this value > but I'm assuming they were telling the truth about numbers (at least, > while I have some doubts about explanation of those numbers). > Can anyone say something about this? Does it sound reasonable? > > Al >Article: 112183
thank you all for ur suggestions and clarifications, they helped me alot. > > right ?Any busmaster in the system can access it. Especially with > a USB2.0 high speed device, you really don't want to move > data with the processor. If the USB device is a AHB slave, > you probably want to use the system's DMA controller as > the master device for data transfer, not the processor. >Article: 112184
I implemented an algorithm into fpga board. I wrote the Matrix data to FPGA board from Matlab and the result came back. I was using a loop to execute the operation many times. It can operate normally for some times, but in the end it stopped with the error in the line : fwrite(sx,datafile,'int8'); and the error messege showed : serial.fwrite A timeout occurred during the write operation. How could it happen? How could it execute some trials but happen time out error at some time?Article: 112185
"Austin Lesea" <austin@xilinx.com> wrote in message news:ejkndb$kkj1@cnn.xsj.xilinx.com... > > phase variations. AM to PM is the bane of our existence: it can not be > prevented, only minimized. Miss one contributor, and you fail to meet > your specification (and delay your project by many months). > Hi Austin, I guess using differential signals is a good way to reduce AM to PM modulation. Is it true that the Virtex4 BUFIO regional clock is a truly differential signal from the BUFIO to the IOB clock pins? I read http://www.xilinx.com/publications/xcellonline/xcell_52/xc_v4xesium52.htm QUOTE:- Each of these input pins or input pin pairs can connect to a BUFIO that drives a high-speed differential I/O clock network, which is dedicated to the I/O circuits and is ideally suited for source-synchronous data capture using the built-in serializer/deserializer (SerDes). END QUOTE So, that's a cool thing. Did you guys do any measurements on the jitter performance of this? I.e. how much jitter is added to a differential data signal coming out of an IOB clocked by a BUFIO driven from a differential clock coming to the FPGA 'Clock Capable' pins.? Cheers, Syms. p.s. I think 1000ps is a lot of jitter even for an FPGA. Low 100's of ps is probably nearer to the mark.Article: 112186
rickman schrieb: > Some of these warnings can be ignored, but some are potentially > signficant problems. > > Unused inputs can be safely ignored. Assigned, but not used can be > ignored if you are sure this is a signal that you intended to not use. > A combinatorial loop may be an error or it may be intentional, but > outside the normal usage of these devices. A combinatorial loop can be > an intended latch or an unintended latch. You need to figure out which > you have. > > The bottom line is that you should design to avoid warnings because > otherwise you need to investigate each one to make sure it is not a > real problem. By leaving them in you need to at least go through the > list each time to make sure no new ones have been generated. > > > learnfpga wrote: > > I am new to CPLD's and I am trying to make a new design incorporating > > some of the old abel code. I am using schematic entry (XC9572). I have > > converted the abel code into symbols and incorporating them to my > > schematic. In the new design I am not using many of the input and > > outputs that were defined in the abel code but I dont want to fiddle > > with that and so I am using the code as it is. > > > > Now when I synthesize I get following warnings.. > > > > WARNING:Xst:647 - Input <A00> is never used. > > > > WARNING:Xst:646 - Signal <CARRY_12> is assigned but never used. > > > > WARNING:Xst:2170 - Unit PN67c : the following signal(s) form a > > combinatorial loop: _xor0004, BEL, _xor0002 > > > > WARNING:Xst:1354 - Port SPAREI is not connected, attached property > > removed (LOC) > > > > > > Should I worry about these warnings because I am not using all these > > ports/signals/input? > > > > At present I have connected all unused inputs to ground and left the > > unused outputs as it is. Is that the right approach? > > > > Thanks for any responses... hi rickman, maybe it is 2 different issues. in my case some inputs that are REALLY used are not present when targetting XC95xx using 8.1 or 8.2 and are present in all other tested target device and ISE version combinations. AnttiArticle: 112187
Al <alessandro.basili@cern.ch> wrote: >Hi to everyone, >I'm developing some electronics to make a time measurement with a >resolution of 25 ps. I'm using a dedicated ASIC to do so Let me guess an Acam part? >Can anyone say something about this? Does it sound reasonable? If you are trying to measure signals with 25ps resolution you have to be extremely careful with *everything* those signals pass through. Passing them through as little as possible would be a good starting approach. --Article: 112188
"terabits" <tera.bits@gmail.com> wrote in message news:1163712948.952378.216490@e3g2000cwe.googlegroups.com... > Hi > > On what factors the maximum operating frequency of ahb master and slave > depends ? > in general what is the maximum frequency we can go for ? > > regards > The upper limit on frequency is in the terahertz range.Article: 112189
How about SOPC Builder? Have any changes been made for permformance improvements while editing? I have never had a problem with long generation times but I have a encountered long delays between adding and editing components. Derek Paul Leventis wrote: > > However, once the timing > > engines have been paralellized in 7.0 or 7.1, expect a more noticeable > > speedup. > > A small correction to Ben's post: Portions of the timing engine are > parallized in this release. > > I should also point out that in addition to parallel compile, there > have been other improvements made for compile time. We're always > pushing on the fitter to reduce compile by general coding & algorithm > improvements, and by being more intelligent about just how much effort > we spend on your design based on how tight your timing & fitting > requirements are. > > Regards, > > Paul Leventis > Altera Corp.Article: 112190
Antti wrote: > rickman schrieb: > > > Some of these warnings can be ignored, but some are potentially > > signficant problems. > > > > Unused inputs can be safely ignored. Assigned, but not used can be > > ignored if you are sure this is a signal that you intended to not use. > > A combinatorial loop may be an error or it may be intentional, but > > outside the normal usage of these devices. A combinatorial loop can be > > an intended latch or an unintended latch. You need to figure out which > > you have. > > > > The bottom line is that you should design to avoid warnings because > > otherwise you need to investigate each one to make sure it is not a > > real problem. By leaving them in you need to at least go through the > > list each time to make sure no new ones have been generated. > > > > > > learnfpga wrote: > > > I am new to CPLD's and I am trying to make a new design incorporating > > > some of the old abel code. I am using schematic entry (XC9572). I have > > > converted the abel code into symbols and incorporating them to my > > > schematic. In the new design I am not using many of the input and > > > outputs that were defined in the abel code but I dont want to fiddle > > > with that and so I am using the code as it is. > > > > > > Now when I synthesize I get following warnings.. > > > > > > WARNING:Xst:647 - Input <A00> is never used. > > > > > > WARNING:Xst:646 - Signal <CARRY_12> is assigned but never used. > > > > > > WARNING:Xst:2170 - Unit PN67c : the following signal(s) form a > > > combinatorial loop: _xor0004, BEL, _xor0002 > > > > > > WARNING:Xst:1354 - Port SPAREI is not connected, attached property > > > removed (LOC) > > > > > > > > > Should I worry about these warnings because I am not using all these > > > ports/signals/input? > > > > > > At present I have connected all unused inputs to ground and left the > > > unused outputs as it is. Is that the right approach? > > > > > > Thanks for any responses... > > hi rickman, > > maybe it is 2 different issues. > > in my case some inputs that are REALLY used are not present > when targetting XC95xx using 8.1 or 8.2 and are present in all > other tested target device and ISE version combinations. I'm not sure what you mean by that. But the bottom line is you need to trace each of the warnings back to the root cause and figure out if it a "real" problem or not. Or you can just fix the warning by connecting your "unused" inputs to something such as an unused output? Like I said, the warning about combinatorial logic loop is not an input issue, you have a potential latch either by intent or unintentional. You need to figure out if that one is a real error or not.Article: 112191
Hi everybody, A part of a project I'm designing is a PCMCIA bus card with a 32 bit data system bus. The system included in the card has a multicore DSP, an ARM processor, some NOR FLASH, SDRAM memory and a FPGA. The FPGA is used for the PCMCIA interface to the system bus and some high speed math as a companion for DSP. The purpose of the whole PCMCIA interface is to transfer some data from the SDRAM into PC, in real time at 33Mhz clock rate. The card data system bus is running at 133MHz. How you'll chose the design for the best card bus interface, knowing there are some fast processes on the internal bus: a. using the FPGA as a slave memory selected by the DSP and implementing a FIFO inside the FPGA . An interrupt request will notice the PC to start download data and empty the FIFO. b. using DMA control over the system bus from the FPGA (FPGA as master, DSP as slave) c. other (please detail) thank you, VasileArticle: 112192
Symon, See below, Austin -snip- > I guess using differential signals is a good way to reduce AM to PM > modulation. Is it true that the Virtex4 BUFIO regional clock is a truly > differential signal from the BUFIO to the IOB clock pins? V4 has an LVDS input, and LVDS output buffer. The signals are single ended inside the IOB, and IOB logic. Where they interface to the global buffers, they go differential again. V4 improves the AM to PM over V2 and V2P, but it is still not perfect (there is that little bit of single ended still there to be influenced, and the differential balance is also never perfect). -snip- > So, that's a cool thing. Did you guys do any measurements on the jitter > performance of this? I.e. how much jitter is added to a differential data > signal coming out of an IOB clocked by a BUFIO driven from a differential > clock coming to the FPGA 'Clock Capable' pins.? Yes, we have performed a great deal of characterization. And the clock capable pins, or even a plain IOB has no real difference in jitter performance. -snip- > p.s. I think 1000ps is a lot of jitter even for an FPGA. Low 100's of ps is > probably nearer to the mark. I agree. Just that we have seen cases where the customer did a number of things that conspired to ruin their day. And, we have seen cases where even with a great deal of jitter, all timing margins were still met, and the design still worked perfectly. For example, if you provide a forwarded clock (source synchronous system) with your data, the clock is likely to jitter around exactly at the same time and direction as the data, and the receiving chip has no trouble at all, even with completely awful peak to peak jitter! I have posted before that in the past, if you connected every single CLB DFF to a global clock bus, and clocked all DFF at the same time (and they all changed state, as in a 0101.. pattern) the device would shut down due to the simultaneous nature of switching everything all at once collapsing the power rails. Virtex 4 SparseChevron(tm) packages were the first family where you could do that, and the rails didn't collapse. Now, this is a pathological case (IMO), but it still makes my point: you can do things that will not work. We are here to help you with techniques that will work.Article: 112193
rickman schrieb: > Antti wrote: > > rickman schrieb: > > > > in my case some inputs that are REALLY used are not present > > when targetting XC95xx using 8.1 or 8.2 and are present in all > > other tested target device and ISE version combinations. > > I'm not sure what you mean by that. But the bottom line is you need to > trace each of the warnings back to the root cause and figure out if it > a "real" problem or not. Or you can just fix the warning by connecting > your "unused" inputs to something such as an unused output? > > Like I said, the warning about combinatorial logic loop is not an input > issue, you have a potential latch either by intent or unintentional. > You need to figure out if that one is a real error or not. rick, in my case the inputs reported as unused are used for sure !!! they are connected by design, and no chance they got optimized away _unless_ the tools _mess_up_, they are used and reported as used in ** ALL ** cases except the combination of: XC95xx and ISE 8.x 100% the same design yields to reports with no warning and proper pin useage. there is nothing to trace the issue, it goes away if I use ISE prior to 8.x or any other device except 95xx AnttiArticle: 112194
jbnote schrieb:
> Hi,
>
> > I just cant belive it, its one of the most useful things for the FPGA
> > SoC designs, and its just not there? I really doesnt have time or fun
> > to reverse engineer the .SOF format only to be able write the data2sof
> > utility for Altera.
>
> I do, which chip do you intend to use ?
>
> the sof is really easy to parse, it's a sequence of option number /
> option length / option data:
>
> typedef struct _bitstream_option {
> uint16_t option; /* le */
> uint32_t length; /* le */
> char data[];
> } PACKED bitstream_option_t;
>
> The RAM data is the option code 19, IIRC. The only hard part is
> figuring how to generate the CRC (option 8, seems like a CRC32,
> but...).
>
> JB
thanks JB
well the ram data is 21
and the CRC is 16 bits, but otherwise it looks like doable to task to
reverse the format
Antti
Article: 112195> I am also interested in this, as I am just completing a design using > OSERDES in Virtex 4 right now - haven't fully simulated yet though. > In your case, where is you clk coming from? Is it coming from a clock > capable input pin, through IBUFDS and BUFIO (then BUFR to create > clkdiv), or is it coming from an internal global clock (eg through a > DCM?) The latter seems to be allowed but I can't see much > documentation, so that may be the cause of the skew... From a DCM and skew might not be the right word for it because it's several clk periods difference. > Also, whenyou say "random delay", do you mean a random skew between the > delay of several OSERDES (e.g. several pins on a fast parallel output > bus), or that the delay varies from one hardware trial to the next, or > just seems non-deterministic wrt the ODDR output? Good question and I wasn't clear. It's non-deterministic on power-up. I am sort of guessing here because I don't have a scope good enough to see these frequencies, however, I have one board talking to another and it seems as if when the transmitting board is repowered or reset, the clkdiv and clk data phase get randomly assigned. I have no problems, thank goodness, if I use all OSERDES transmitters, instead of using OSERDES for data transmitters and an ODDR for clkdiv. > Not many answers so far I'm afraid, but I will post my own results soon > if it is helpful. Please do post. Thanks. Brad Smallridge AiVisionArticle: 112196
Antti wrote: > rickman schrieb: > > > Antti wrote: > > > rickman schrieb: > > > > > > in my case some inputs that are REALLY used are not present > > > when targetting XC95xx using 8.1 or 8.2 and are present in all > > > other tested target device and ISE version combinations. > > > > I'm not sure what you mean by that. But the bottom line is you need to > > trace each of the warnings back to the root cause and figure out if it > > a "real" problem or not. Or you can just fix the warning by connecting > > your "unused" inputs to something such as an unused output? > > > > Like I said, the warning about combinatorial logic loop is not an input > > issue, you have a potential latch either by intent or unintentional. > > You need to figure out if that one is a real error or not. > > rick, > > in my case the inputs reported as unused are used for sure !!! > they are connected by design, and no chance they got optimized away > _unless_ the tools _mess_up_, they are used and reported as used in ** > ALL ** cases except the combination of: > > XC95xx and ISE 8.x > > 100% the same design yields to reports with no warning and proper pin > useage. > > there is nothing to trace the issue, it goes away if I use ISE prior to > 8.x or any other device except 95xx I got you mixed up with the OP.Article: 112197
On Nov 17, 6:50 am, "Antti" <Antti.Luk...@xilant.com> wrote: > I just cant belive it, its one of the most useful things for the FPGA > SoC designs, and its just not there? I really doesnt have time or fun > to reverse engineer the .SOF format only to be able write the data2sof > utility for Altera. Antti, Others have commented on the general-purpose case, but since you made a specfiic reference to processors its worth discussing the soft-CPU flow for placing your code/data into onchip ram. No, this wasn't forgotten. In fact, support for doing this has been around about as long as Nios I/Nios II have been (6+ years now?). There are even several ways to accomplish the task: - If you are building your Nios II software in the IDE, it will take any coce/data linked into an onchip memory peripheral and use the elf2hex command to create a hex initialization file. The onchip RAM RTL generated by SOPC Builder is written out to be initialized this way; if you compile your design w/o any software having been built, memory will be left un-initialized, while if you first compile your software and then (re)compile in quartus, the .hex file(s) are used to initialize the memories. If you turn on verbose command line output from the IDE (window -> preferences -> nios II), you'll see the precise commands fly by on the console for future reference and command- line use. - Although the IDE-based flow doesn't do this now, you can even update your .sof file very quickly with onchip ram contents without risk of triggering an entire re-compile. I cannot recall the exact syntax of the command but I believe the compilation step is the Quartus Assembler (quartus_asm) - The "small" example design that ships with Nios II uses the above IDE-based method to initialize onchip RAM and as I recall the design's readme and other literature discuss this. Note that there are exclusions to what I've said, specifically for the types of onchip ram (m-ram blocks in Stratix, Stratix II) that cannot be initialized until runtime. The wizard to create an onchip ram in SOPC Builder allows you to choose which type of ram block will be used, if you desire, to ensure that you can pre-initialize contents if that is what you need to do. Jesse Kempa Altera Corp. jkempa --at-- altera --dot-- comArticle: 112198
rickman schrieb: > Antti wrote: > > rickman schrieb: > > > > > Antti wrote: > > > > rickman schrieb: > > > > > > > > in my case some inputs that are REALLY used are not present > > > > when targetting XC95xx using 8.1 or 8.2 and are present in all > > > > other tested target device and ISE version combinations. > > > > > > I'm not sure what you mean by that. But the bottom line is you need to > > > trace each of the warnings back to the root cause and figure out if it > > > a "real" problem or not. Or you can just fix the warning by connecting > > > your "unused" inputs to something such as an unused output? > > > > > > Like I said, the warning about combinatorial logic loop is not an input > > > issue, you have a potential latch either by intent or unintentional. > > > You need to figure out if that one is a real error or not. > > > > rick, > > > > in my case the inputs reported as unused are used for sure !!! > > they are connected by design, and no chance they got optimized away > > _unless_ the tools _mess_up_, they are used and reported as used in ** > > ALL ** cases except the combination of: > > > > XC95xx and ISE 8.x > > > > 100% the same design yields to reports with no warning and proper pin > > useage. > > > > there is nothing to trace the issue, it goes away if I use ISE prior to > > 8.x or any other device except 95xx > > I got you mixed up with the OP. ok, yes I should have realized that. if a design gives similar warning regardles the target device selection then the OP may have other issues - its always a good idea to get rid of warnings if it is possible AnttiArticle: 112199
kem...@yahoo.com schrieb: > On Nov 17, 6:50 am, "Antti" <Antti.Luk...@xilant.com> wrote: > > I just cant belive it, its one of the most useful things for the FPGA > > SoC designs, and its just not there? I really doesnt have time or fun > > to reverse engineer the .SOF format only to be able write the data2sof > > utility for Altera. > > Antti, > > Others have commented on the general-purpose case, but since you made a > specfiic reference to processors its worth discussing the soft-CPU flow > for placing your code/data into onchip ram. > > No, this wasn't forgotten. In fact, support for doing this has been > around about as long as Nios I/Nios II have been (6+ years now?). There are even > several ways to accomplish the task: > > - If you are building your Nios II software in the IDE, it will take > any coce/data linked into > an onchip memory peripheral and use the elf2hex command to create a hex > initialization > file. The onchip RAM RTL generated by SOPC Builder is written out to be > initialized this > way; if you compile your design w/o any software having been built, > memory will be left > un-initialized, while if you first compile your software and then > (re)compile in quartus, > the .hex file(s) are used to initialize the memories. > > If you turn on verbose command line output from the IDE (window -> > preferences -> nios II), > you'll see the precise commands fly by on the console for future > reference and command- > line use. > > - Although the IDE-based flow doesn't do this now, you can even update > your .sof > file very quickly with onchip ram contents without risk of triggering > an entire > re-compile. I cannot recall the exact syntax of the command but I > believe the compilation > step is the Quartus Assembler (quartus_asm) > > - The "small" example design that ships with Nios II uses the above > IDE-based > method to initialize onchip RAM and as I recall the design's readme and > other > literature discuss this. > > Note that there are exclusions to what I've said, specifically for the > types of > onchip ram (m-ram blocks in Stratix, Stratix II) that cannot be > initialized until > runtime. The wizard to create an onchip ram in SOPC Builder allows you > to > choose which type of ram block will be used, if you desire, to ensure > that you > can pre-initialize contents if that is what you need to do. > > Jesse Kempa > Altera Corp. > jkempa --at-- altera --dot-- com Dear Jesse, I know about all you said above. but you missed the point. in Xilinx flow you can run a tool like: data2mem system.bit software.elf download.bit it will take the FPGA design (with soft cpu) and merge the elf file __into__ it. in Lattice flow you *can* do the same. in Altera flow this is ASFAIK __not_possible__ at all. What I need a very simple thing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> my_design.sof + my_software.elf => my_ready_to_program.sof >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I see no other way as doing full RE on the SOF to accomplish that. its stupid, and I would REALLY like to use Altera tools to do that, but if Altera is not able to provide such an important tool/option then someone has todo it (I really would prefer to spend my time with other things than doing RE on altera file formats) Antti
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