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
> I'd like to thank you John for your > advice about ARM's lawyers. But i do not know the ramifications you're > implying. Could you explain it further if possible. ARM have several patents that cover various features within their architecture (exception handling / mul/mac instructions etc). They have been known in the past to bully individuals / companies in to stopping their projects/products that they believe infringe on their patents. Search the web for nnARM and picoTurbo. Cheers, JonArticle: 66926
Hello there I'm having serious problems configuring my FPGA using EPC2. We have designed the circuit exactly as stated in the Altera datasheet and even played around with the pullups and buffering that's recommended. To be more specific, We have a board with a FLEX10KE (EPF10K200SBC356-1) and a EPC2LC20 for in-system configuration. We also have provided for direct Byteblaster configuration using a connector (using the same path towards the FPGA and selecting between them through enabling/disabling a buffer). Finally, we have a JTAG connector by which we can configure the FPGA directly using the SOF file generated by Quartus - pls read below. Anyway, what we're seeing is: The EPC2 gets progammed OK but then the problems start. When I turn the system off and on again to initiate configuration the nCONFIG pin comes out of reset and so does nSTATUS but only for a very small amount of time. During this time DCLK goes enabled and DATA transfers configuration data, as normally. Then nSTATUS goes low again and the configuration is interrupted as you would expect. There is nothing in the circuit that could pull this pin low - it is a point to point connection between FPGA and EPC2. It seems however that the EPC2 goes back on reset state hence pulling its OE pin low. From that point onwards these signals are going crazy, ie they randomly go high or low so the FPGA never gets configured. Tried using external pullups whilst disabling the internal ones through Quartus, but there was no change. One last point is that so far I've been configuring the FPGA through a direct JTAG connection using the SOF file - this works fine. Does this perhaps confuse the device, ie how does it know whether it should be programmed through JTAG or EPC2. Do I need to set something there? Finally, I'm using the POF file to program the EPC2 - I'm assuming this is correct?? Please give me some feedback because I'm really stuck with this. Any tips would be much welcome. Thanks in advanceArticle: 66927
"chi" <huageng.chi@vtt.fi> wrote in message news:c1t4vs$idb$1@lilja.vtt.fi... > Hi, friends, > > I'm following Altera Nios hardware tutorial for apex development board. I > cannot run the hello_nios.srec SDK display: > > nios-run: Ready to download hello_nios.srec over COM1: at 115200 bps > : Press CPU Reset (or CLEAR) on target board to begin download > : Type Control-C to exit the program > : Waiting for target..... > > Did anybody meet this problem? > This is perhaps a silly question, but did you try pressing the cpu reset button? If the processor is off running something else, then it won't be listening on the com port, and you need to reset it to get it back to the monitor program. Also try running nios-run as a simple terminal "nr -t" and reset the processor - assuming you are using the standard monitor program, it should print a basic message on the terminal so that you can see that it's working.Article: 66928
Max wrote: > > OE will strip off the lines at the end of the post, and claim that > they constitute an attachment named > "to illustrate all of OE's misbehaviour, but this paragraph.dat" > - ROTFLMAO! > > There's also a massive security hole there, though I don't think I'll > go into detail. It's only one such flaw amongst a multitude, however. The hole is smaller than you think, since the "attachment" is empty. Presumably OE didn't find the end of the attachment so just threw the contents away. :)Article: 66929
"Paul Leventis \(at home\)" <paul.leventis@utoronto.ca> wrote in message news:<j2B0c.53313$ah.15341@twister01.bloor.is.net.cable.rogers.com>... > Of course, you can't take this argument to extremes. Working against larger > LUTs is your ability to map designs into these larger functions. If most of > your design maps into 4-input functions and you have a 6-LUT architecture, > you'll be wasting a lot of silicon and a 4-LUT based product will be more > efficient. For these reasons, there is a bottom to the curve -- a 25-LUT > architecture would not be more area efficient than a 4-LUT architecture! > Where that bottom is... well, there's lots of academic studies and we've got > our own data. The older academic data that I have seen suggests that the optimum is somewhere between 4-LUTs and 5-LUTs for non-arithmetic circuits. It makes sense that these numbers shift to larger LUTs when the number of routing levels increases and also when the transistors shrink faster than the routing density. (Which seems to be the case for modern technologies). But silicon area is not everything. Because of the large area that is dedicated to routing in FPGAs, in generally makes sense (area wise) to have an architecture that is a little short on routing. (Better waste unused LUTs than waste unused routing). But it turned out that both the CAD tool developers and the customers did not like this because the flow (in the tools and in the heads) is to place first and route second. This flow becomes a lot easier when the routing is guaranteed to succeed. Therefore most commercial FPGA we see today target a 100% LUT utilization. This is expensive. But it really helps time to market wise. Kolja SulimmaArticle: 66930
Dimitris Kontodimopoulos wrote: > Hello there > > I'm having serious problems configuring my FPGA using EPC2. We have > designed the circuit exactly as stated in the Altera datasheet and > even played around with the pullups and buffering that's recommended. > To be more specific, We have a board with a FLEX10KE > (EPF10K200SBC356-1) and a EPC2LC20 for in-system configuration. We > also have provided for direct Byteblaster configuration using a > connector (using the same path towards the FPGA and selecting between > them through enabling/disabling a buffer). Finally, we have a JTAG > connector by which we can configure the FPGA directly using the SOF > file generated by Quartus - pls read below. > Anyway, what we're seeing is: > The EPC2 gets progammed OK but then the problems start. When I turn > the system off and on again to initiate configuration the nCONFIG pin > comes out of reset and so does nSTATUS but only for a very small > amount of time. During this time DCLK goes enabled and DATA transfers > configuration data, as normally. Then nSTATUS goes low again and the > configuration is interrupted as you would expect. There is nothing in > the circuit that could pull this pin low - it is a point to point > connection between FPGA and EPC2. It seems however that the EPC2 goes > back on reset state hence pulling its OE pin low. From that point > onwards these signals are going crazy, ie they randomly go high or low > so the FPGA never gets configured. Tried using external pullups whilst > disabling the internal ones through Quartus, but there was no change. > One last point is that so far I've been configuring the FPGA through a > direct JTAG connection using the SOF file - this works fine. Does this > perhaps confuse the device, ie how does it know whether it should be > programmed through JTAG or EPC2. Do I need to set something there? > Finally, I'm using the POF file to program the EPC2 - I'm assuming > this is correct?? Please give me some feedback because I'm really > stuck with this. Any tips would be much welcome. Thanks in advance is your setup able to program both, FPGA and EPC2 through JTAG ? Yes, a pullup on TMS, TDI and a pulldown on TCK. AN116 shows all that nicely. Yes, SOF for the RAM, POF for the EEPROM parts. The pullup and pulldown make the control lines to have the right state such that the FPGA is loaded from the EPC2 at powerup. Then the reportfile *.rpt gives an assumed pin useage, especially for those pin you did not use. I also recently learnt that there may not be any open inputs on certain families. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 66931
Hi Matt, I mean: You have a board with a few fpga´s running your partinioned design. You record all IO´s into RAM on the fastes clock (how much depends on your RAM size). After a trigger you stop and download the RAM. With this information you step into the netlists, to explore the internal signals. I think every boolean equation could be calculated, so every signal is visible - 100%. clear? kind regards, thomas "Matt" <bielstein2002@comcast.net> schrieb im Newsbeitrag news:L_A0c.91758$4o.116746@attbi_s52... > What? > > "T. Irmen" <tirmen@gmx.net> wrote in message news:c1qp3p$dbi$1@online.de... > > Hi, > > > > to everyone who thought about doing calculations with netlists . eg. > > external pins, internal states are known (from reset state) to figure out > > the remaining signals, lets say 100% visibility. > > > > Does anybody thought about that? > > > > kind regards, > > thomas > > > > > >Article: 66932
Hi Kolja, > Because of the large area that is dedicated to routing in FPGAs, in > generally makes sense (area wise) to have an architecture that is a > little short on routing. (Better waste unused LUTs than waste unused > routing). >[Snip] > This flow becomes a lot easier when the routing is guaranteed to > succeed. > Therefore most commercial FPGA we see today target a 100% LUT > utilization. > This is expensive. But it really helps time to market wise. Yes, the academic literature suggesting this is a interesting (Andre DeHon had a paper at FPGA a few years back, I think). In our own experimentation, we see that different designs (obviously) have varying amounts of routing demand per logic element. If you try to build a chip that allows all designs to route, you'll have way too much routing for most designs. But as you point out, customers aren't too happy if they have a 90% full device that fails to route. And it's mostly a problem when they've done most of their design (and it fits), only to find that late in the game when they add a few more LEs, suddenly they can't route anymore. And when customers run into problems, it costs us in support time, customer loyalty, lost business, etc. So there are cost pressures that push us in the direction of being slightly over-routed. That said, our devices do make use of the less-than-100% observation, but in more local ways. For example, a LAB in Stratix has 30 general routing inputs (lab lines), and has 10 4-input LEs. Obviously, you could construct a LAB that would be (deterministically) unroutable. It would just not be efficient to build a LAB architecture with 40+ inputs, since Quartus can almost always find LEs that share input signals or feedback to one another in order to reduce input demands, and thus most LABs would have a lot of wasted input muxes. When it can't, it automatically will leave some LEs in a LAB unused in order to cap the number of inputs in use. This is like a localized version of the "don't hit 100%" approach. There is a large body of good academic research on the optimal # of cluster inputs for a given # of BLEs (Rose, Betz, E. Ahmed, Singh, Kouloheris, D. Hill, etc.). There is also research that shows that you should aim to never use the full # of LAB inputs, as this is more efficient than trying to make a fully utilized set of inputs routable (Guy Lemieux). Regards, Paul Leventis Altera Corp.Article: 66933
Dear Sir or Madam,
when you go to the linked site you see the simulation plots
(functional simulation) of the SRAM controller
which I am designing for the SRAM CY7C1399B.
There are shown the sram_address, sram_data and the control signals
Oe_bar, Cs_bar, We_bar
for writing to a location and reading from this location later.
But when trying to read from that location the data bus is in
undefined state ('U').
The reasons could be:
1. writing to that address was not done correctly so that the written
data is corrupted.
2. reading is not done correctly
Where could be the problem?
I would be very thankful for some useful hint..
Andrés Vázquez
p.s. Do the changed timing constants in CY7C199.vhd take affect when
doing a functional simulation ?
http://mitglied.lycos.de/vazquez78/
Article: 66934
sorry for the delay, have been off work.
-- --------------------
RSTl <= transport '1';
BUSY <= transport '0';
EMPTY <= transport '1';
AS_DSl <= transport '0';
ADIO <= transport std_logic_vector'("ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ");
-- --------------------
WAIT FOR 4 ns; -- Time=4 ns
CHECK_ADIO("ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ",4); --Z
that is the main set and check process used for the bidirectional signal
ADIO.
does this help?
Mike
MM wrote:
>>here is a copy of the top module entity declaration.
>
>
> This doesn't help much. We need to see how you drive the signal.
>
>
>>I can add in the code from the auto-generated testbench as well if you
>
> like?
>
> Yes, but only the lines relevant to the signal of interest...
>
> /Mikhail
Article: 66935
"Terrence Mak" <stmak@se.cuhk.edu.hk> wrote in message news:<c1u8a3$24vn$1@justice.itsc.cuhk.edu.hk>...
> Hi,
>
> I am new in using the embeded device (VirtexII-Pro) to implement an
> algorithm.
> As I want to count the cpu time of the algorithm , I use the
> XTime_GetTime(starttime) in the the xtime_l.h library.
> Also I need to print out the result to a uart by using xil_printf. But the
> result did not displayed successfully.
> Please find the program as follows.
>
> Is there any step missed?
>
> Many thanks,
> Terrence
The following statements only allocate pointers, not a memory
array or structure pointed to. I'm not sure if the XTime_GetTime()
function allocates memory for you, but I'm sure than sprintf does not.
Thus you're calling functions with uninitialized pointers and
the result is stored (probably at location zero) where the
pointers were at the time of call.
> XTime *starttime, *endtime;
> char *output;
if instead you wrote:
XTime starttime, endtime;
char output[16]; // or as large as the largest message
xil_printf("start\n");
XTime_GetTime(&starttime);
// Start computation
...
//End computation
XTime_GetTime(&endtime);
//convert the long long to a string
sprintf(output, "%llu", endtime);
...
you should have better results
Article: 66936Paul, You answered my questions, It will be an interesting springtime, Thanks, Austin Paul Leventis (at home) wrote: > Hi Austin, > > [To answer your technical/architectural questions] > > >>I was unclear on just how a ALM is any different from drawing the box >>differently around the components. I am still puzzled, but the block >>diagrams appears to have 3, 4, 5 and 6 LUTS with muxes, and maybe if it >>was actually designed this way then that is simply what it is. A true 6 >>LUT has 64 memory cells and the associated logic, and two of these seems >>a bit excessive and would not require any other logic or muxes at all. >> Combining existing 4 LUTs to deliver some of the possible terms of a 6 >>LUT is a completely different matter. > > > I would highly recommend looking at Figure 2-6 of the Stratix II databook to > gain a better understanding of exactly what hardware there is in the ALM. > > The Stratix II ALM can implement all functions of 6 inputs, since it has 64 > bits of LUT memory. It can also implement two independent 4-LUTs, a 5-LUT > and 3-LUT, two 6-LUTs that share a LUT mask and 4 inputs, two 5-LUTs that > share part of their LUT mask plus 2 inputs, a subset of 7-input LUTs, etc. > Plus there are a variety of ways to combine this functionality with > registers before, after, or independent of the logic, and some gunk for > powerful arithmetic. > > First the simple question: How does a 6-LUT differ from 4 4-LUTs + 3 2:1 > muxes (ala 2 slices, 2 f5 muxes and an f6 mux)? It is not just where you > draw the boxes. The silicon area per logic function (or logic efficiency) > is much better with a 6-LUT, and this is largely due to area for > user-programmable routing. > > In a 4-LUT architecture, the LUTs are designed to be independent, thus there > are 4 independently routable signals to each LUT. The fx muxes also require > a control input, which for now we will assume is independently routed. Thus > to implement a 6-input function using a 4-LUT architecture and fx muxes > requires a total 19 independently routed signals. This implies 19 routing > multiplexers which burn area and power. With a 6-LUT, obviously only 6 > routing inputs would be required. So the potential area savings of a 6-LUT > come not from a reduction in LUT mask RAM bits (both require 64) but from a > reduction in user-configurable routing multiplexers. > > Of course, you can't take this argument to extremes. Working against larger > LUTs is your ability to map designs into these larger functions. If most of > your design maps into 4-input functions and you have a 6-LUT architecture, > you'll be wasting a lot of silicon and a 4-LUT based product will be more > efficient. For these reasons, there is a bottom to the curve -- a 25-LUT > architecture would not be more area efficient than a 4-LUT architecture! > Where that bottom is... well, there's lots of academic studies and we've got > our own data. > > But the Stratix II ALM is more than a 6-LUT architecture. It targets the > routing area efficiency gains of larger LUTs, while attempting to minimize > the wastage that occurs when you need to implement small logic functions. > It provides a few extra inputs (8 instead of 6) and one extra output (2 > instead of 1), and is thus slightly less efficient than a true 6-LUT > architecture for implementing 6-input functions. However, these inputs and > outputs plus a few internal 2:1 muxes allow us to make use of the full ALM > under a wide range of function sizes by allowing us to fracture the ALM into > independent/semi-dependent functions. This allows us to greatly reduce the > number of LUT mask bits that go unused, and allows us to highly utilize the > available inputs and outputs of the ALM, resulting in little wasted silicon > area for input/output routing. > > Why 8 inputs, 2 outputs, and all the little 2:1 muxes? Because our > experiments in the end showed that this resulted in the best combination of > area and performance, and I can assure you we believed there to be a > substantial benefit over the Stratix ALE in order to commit the resources > required to support a completely new logic fabric. > > On a performance front, larger input LUTs confer a benefit in terms of > critical path delay by reducing the number of levels of logic and thus > routing hops required to a implement a given cone of logic. But is an 6-LUT > based ALM faster than 4-LUT based slices + fx muxes? A paper analysis will > not answer this, since both implement 6-input functions (albeit at different > area efficiencies). I could start arguing that smaller area turns > into/gives area to be spent on better speed, or start counting > transistors/gates in the path, but then we'd be getting into a very fuzzy > realm full of a gazillion assumptions! > > >>Regardless, it is enjoyable to hear about any radical or innovative new >>architecture, as there are so many that now dot the landscape as dead >>skeletons of past FPGAs. > > > And I must say it was enjoyable to have worked on a radical, innovative > architecture such as Stratix II. And given its enhancements over the > successful Stratix architecture, I expect it to be flesh-covered and alive > for a long while. > > Regards, > > Paul Leventis > Altera Corp. > >Article: 66937
Kevin Brace wrote: > Is the book you are using called Verilog Digital System Design by > Zainalabedin Navabi? > It sounds like that because that book gets into boring stuff like > structural modeling. Bhasker, "A verilog HDL Primer." I also have the synthesis book, which I'll read after the primer. I figured I'd be safe doing some real-world projects using structural modeling, since there isn't much to think about in terms of synthesis issues at this level. So there's another book that deals with boring structural modeling! > Right, you probably should avoid using vendor specific features > if there is no benefit like performance gain or logic resources > reduction. > Otherwise, keeping the logic generic makes sense for portability > reasons. I see. Thanks for the input. Good day! -- ____________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.govArticle: 66938
Hi,
I'm trying to code this structure in Verilog. There are two flip
flops (c and d) that are identical. XST 6.1.3 wants to merge them
together. I want to stop it from doing that.
e .---. c
+-----|D Q|-----
| +-|>C |
a .---. b | | | |
----|D Q|-----+ | '---'
+--|>C | | |
| | | | |
| '---' | f | .---. d
| +-----|D Q|-----
clk-+----------------+-|>C |
| |
'---'
created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de
I am giving the -equivalent_register_removal YES option to XST (it's
needed elsewhere in the design) so I have to use attributes to stop
XST from merging these particular ffs, since I don't wish to
instantiate unisim components.
When I use the keep attribute on all of c, d, e and f, XST still
merges the ffs, and comes back with this warning:
WARNING:Xst:638 - in unit foo Conflict on KEEP property on signal e
and f f signal will be lost.
[ Warning 638 isn't in the Xilinx documentation or the answers
database. ]
Here's the Verilog:
module foo
(
input wire clk,
input wire a,
output reg c,
output reg d
);
reg b;
wire e = b;
wire f = b;
// synthesis attribute keep of c is "true"
// synthesis attribute keep of d is "true"
// synthesis attribute keep of e is "true"
// synthesis attribute keep of f is "true"
always @(posedge clk)
begin
b <= a;
c <= e;
d <= f;
end
endmodule
I have a working solution: add BUFs as follows:
BUF buf_e (.I(b), .O(e));
BUF buf_f (.I(b), .O(f));
This produces the correct result after synthesis, but I wish to avoid
using unisim components, because (1) they slow my simulation (even BUF
contains a specify block!), (2) they aren't portable, and (3) I
shouldn't have to.
Questions:
- What am I doing wrong? ("Expecting too much from XST" is not an
acceptable answer.)
- How can I write the Verilog such that I get the correct result after
synthesis without needing to instantiate unisim components?
Hint to Xilinx: a "preserve" attribute would be really handy. The
other synthesis vendors have it. Why doesn't XST?
Thanks,
Allan.
Article: 66939On Tue, 02 Mar 2004 05:08:06 +1100, Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote: [snip] >I have a working solution: add BUFs as follows: > >BUF buf_e (.I(b), .O(e)); >BUF buf_f (.I(b), .O(f)); Note: if I use buf (Verilog primitive) instead of BUF (Xilinx unisim component) it will merge the flip flops. Presumably bufs get stripped out fairly early during synthesis. Regards, Allan.Article: 66940
Peter Alfke <peter@xilinx.com> wrote in message news:<BC65017B.3AC3%peter@xilinx.com>... > I have to agree with rickman ( in spite of his harsh wording) > The issue is not square millimeters, the issues are: > Capacity, performance, and price (and power, familiarity and software > support) <snip> I think we are just seeing things from different points of view. I was just suggesting a better method for tool-flow+fabric comparison than that used in the referenced Altera white paper. I agree that many other variables will affect who gains more market share. (Perhaps this is because not all that much separates the two solutions on a tool-flow+fabric basis?) <snip> > Thank God we are not (yet) selling FPGAs by the square millimeter. > > And BMW, Lexus and Cadillac are still not selling their cars by the pound, > or even the cubic inch. And those products have more than a hundred-year > evolution behind them... For fun I would argue that the FPGA customer is more discerning from an engineering perspective than the car customer!Article: 66941
Kevin Neilson wrote: > "valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in > message news:c1qck8$1ld1dc$1@ID-212430.news.uni-berlin.de... > >>There is a netlist synthesied, say, for an ASIC technology. The netlist >>should be prototyped on FPGA. Therefore, it should be implemented by FPGA >>vendor's tools. Implementation should be done automatically for any > > netlist > >>given in EDIF format. Functionality of primitives is known. One of the >>solutions is to create a VHDL netlist and resynthesize. It would be > > possible > >>to bypass VHDL export and synthesis by building (on-the-fly) a > > macro-library > >>of the ASIC primitives out of vendor's primitives, specifically out of >>Xilinx's UniSim primitives. Please, give the idea, what are the macro-libs >>and how can they be created? Thanks. >> > > I think it would be possible to make, say, a Perl script that would convert > ASIC primitives into FPGA primitives. I don't know if it would be very > efficient, though. The ASIC primitives will be things like AND gates, > whereas the FPGA primitives are LUTs that can absorb several gates. A very > simple scripts would map a single gate to a single LUT and not be efficient, > so the best bet is to resynthesize the source if you can. I suppose if you > could do that, you wouldn't be asking the question though. > -Kevin > What is worse than this is the fact that translating a netlist in this manner eliminates the possibility of using the carry chain, dedicated muxes (MUXF5/6/7/8), and other "special" logic resources (i.e. SRL16, MULTAND, etc.). It has the likelihood of not fully utilizing the capabilities of the registers (i.e. clock enables and synchronous resets mapped into general logic) and makes it very difficult and unlikely that much of the dedicated RAM and Multiplier structures will be used. It also lends itself more to misusing routing resources (i.e. not using global routes properly for clocks, local connects, etc.). In the end you are likely to use a much larger FPGA running at a fraction of the speed possible and will likely be harder to get quickly up and runnning and more difficult to debug as well which I assume is the whole purpose of using the FPGA for prototyping. As mentioned before, it is a much better route to use RTL code and synthesize directly to the FPGA architecture you are targeting than to take a netlist mapped to one technology library and remap it to an FPGA. -- BrianArticle: 66942
dkonto@isd.gr (Dimitris Kontodimopoulos) wrote in message news:<1609ee5e.0403010148.1b9c61df@posting.google.com>... > Hello there > > I'm having serious problems configuring my FPGA using EPC2. We have > designed the circuit exactly as stated in the Altera datasheet and > even played around with the pullups and buffering that's recommended. > To be more specific, We have a board with a FLEX10KE > (EPF10K200SBC356-1) and a EPC2LC20 for in-system configuration. We > also have provided for direct Byteblaster configuration using a > connector (using the same path towards the FPGA and selecting between > them through enabling/disabling a buffer). Finally, we have a JTAG > connector by which we can configure the FPGA directly using the SOF > file generated by Quartus - pls read below. > Anyway, what we're seeing is: > The EPC2 gets progammed OK but then the problems start. When I turn > the system off and on again to initiate configuration the nCONFIG pin > comes out of reset and so does nSTATUS but only for a very small > amount of time. During this time DCLK goes enabled and DATA transfers > configuration data, as normally. Then nSTATUS goes low again and the > configuration is interrupted as you would expect. There is nothing in > the circuit that could pull this pin low - it is a point to point > connection between FPGA and EPC2. It seems however that the EPC2 goes > back on reset state hence pulling its OE pin low. From that point > onwards these signals are going crazy, ie they randomly go high or low > so the FPGA never gets configured. Tried using external pullups whilst > disabling the internal ones through Quartus, but there was no change. > One last point is that so far I've been configuring the FPGA through a > direct JTAG connection using the SOF file - this works fine. Does this > perhaps confuse the device, ie how does it know whether it should be > programmed through JTAG or EPC2. Do I need to set something there? > Finally, I'm using the POF file to program the EPC2 - I'm assuming > this is correct?? Please give me some feedback because I'm really > stuck with this. Any tips would be much welcome. Thanks in advance Hi Dimitris, Generally, when nSTATUS goes low, it is because the FPGA has seen corrupted data. It knows this because each frame of data has a checksum, so if the frame is corrupted the computed and transmitted checksum don't match. The most common cause of corrupted data is double-clocking on DCLK. So the first thing I suggest is to monitor DCLK, as close as possible to the device. You are in a BGA, so the best would be to probe under the board. If you have noise on DCLK, this can show up as double clocking. Your buffer may have fast drivers, and that's not always good - an unterminated line driven by a fast-switching driver can exhibit ringing which will cause clocking problems. Another possibility is that the connection through the buffer is causing a problem with the DCLK vs DATA timing. This is unlikely but possible - imagine that DCLK is shifted vs DATA, then the tSU and tH may not be met. So you can check that as well. For the specific question about JTAG: you select which configuration mode you want by setting the MSEL pins. The JTAG config works for any valid combination of MSEL pins. When the FPGA sees the JTAG "config" instruction coming in on TDI and TCK it then starts to configure by JTAG. You probably have the MSEL pins set correctly since configuration begins correctly - but it's worth a check. Altera has developed a Configuration Troubleshooter to help debug configuration issues. It's on http://www.altera.com/cgi-bin/ts.pl?fn=configuration I encourage you to give it a try, as this can solve most configuration issues, and it's open 24/7! Sincerely, Greg Steinke gregs@altera.com Altera CorporationArticle: 66943
rickman <spamgoeshere4@yahoo.com> wrote in message > > At this point, I understand the ACEX hardware. But I can't put gates > anywhere. I am asking how to control this from my VHDL. In the Xilinx > parts, you use a symbol to drive a global reset net. The tools then > remove the symbol and use the GSR feature to control the FFs reset > function. I have no idea how to do this in VHDL for the ACEX parts. > Hi Rick, sorry that I didn't understand the question! To use the chip wide reset, you turn on an option in the tool (whether Quartus II or MAX+PLUS II). You do not code it in VHDL. In MAX+PLUS II, this is enabled through the Enable Chip-Wide Reset option in the MAX+PLUS II software under Global Project Device Settings (Assign menu). In Quartus II you can do this through the Assignment Editor. If you want to use some of the global reset lines (different from the chip wide reset), you can code that in VHDL and they will be used automatically as long as you don't use more than exist. If you use more than exist than the non-global routing will be used. Sincerely, Greg Steinke gregs@altera.com Altera CorporationArticle: 66944
Mike,
Here is an example that works:
--------------------------------------------------
-- Entity Foo
--------------------------------------------------
library IEEE;
use IEEE.std_logic_1164.all;
entity foo is
port (
ADIO: inout STD_LOGIC
);
end foo;
architecture foo_behav of foo is
begin
process
begin
ADIO <= 'Z';
wait for 10 ns;
ADIO <= '1';
wait;
end process;
end foo_behav;
--------------------------------------------------
--
-- Title : Test Bench for Foo
--
--------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
entity foo_tb is
end foo_tb;
architecture TB_ARCHITECTURE of foo_tb is
component foo
port(
ADIO : inout std_logic
);
end component;
signal ADIO : std_logic;
begin
UUT : foo
port map (
ADIO => ADIO
);
adio <= 'Z';
end TB_ARCHITECTURE;
configuration TESTBENCH_FOR_foo of foo_tb is
for TB_ARCHITECTURE
for UUT : foo
use entity work.foo(foo_behav);
end for;
end for;
end TESTBENCH_FOR_foo;
I think your problem is that you are assigning the signal with a concurrent
statement in both your entity and the test bench. The simulator estimates
these only once and leaves the signal at the value that was assigned last...
/Mikhail
Article: 66945Greg Steinke wrote: > > rickman <spamgoeshere4@yahoo.com> wrote in message > > > At this point, I understand the ACEX hardware. But I can't put gates > > anywhere. I am asking how to control this from my VHDL. In the Xilinx > > parts, you use a symbol to drive a global reset net. The tools then > > remove the symbol and use the GSR feature to control the FFs reset > > function. I have no idea how to do this in VHDL for the ACEX parts. > > > Hi Rick, sorry that I didn't understand the question! > > To use the chip wide reset, you turn on an option in the tool (whether > Quartus II or MAX+PLUS II). You do not code it in VHDL. In MAX+PLUS > II, this is enabled through the Enable Chip-Wide Reset option in the > MAX+PLUS II software under Global Project Device Settings (Assign > menu). In Quartus II you can do this through the Assignment Editor. > > If you want to use some of the global reset lines (different from the > chip wide reset), you can code that in VHDL and they will be used > automatically as long as you don't use more than exist. If you use > more than exist than the non-global routing will be used. Ok, thanks. But I am still a bit confused about how to get a FF preset. Even if this uses the inverter method, how does the synthesis tool know my FF output is active low vs. active high? Everything I read seems to indicate that this is only controled if you are using explicit signals to preset/clear the FF and the chipwide reset will operate the same way this explicit signal works. I don't want to use an explicit reset signal, I only want to use the chipwide signal, but I still want to make some FFs presettable. Do I have to make my HDL code reflect this explicitly by making every signal default state a '0'? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 66946
Try: // synthesis attribute equivalent_register_removal of c is "no" // synthesis attribute equivalent_register_removal of d is "no" and see if that does what you want it to. -- Brian Allan Herriman wrote: > On Tue, 02 Mar 2004 05:08:06 +1100, Allan Herriman > <allan.herriman.hates.spam@ctam.com.au.invalid> wrote: > > [snip] > >>I have a working solution: add BUFs as follows: >> >>BUF buf_e (.I(b), .O(e)); >>BUF buf_f (.I(b), .O(f)); > > > Note: if I use buf (Verilog primitive) instead of BUF (Xilinx unisim > component) it will merge the flip flops. Presumably bufs get stripped > out fairly early during synthesis. > > Regards, > Allan.Article: 66947
Hi: As I understand it, the Impact tool doesn't work with Parallel IV cables, which my experience confirms. Also, I had a plethora of other problems when I attempted to upgrade to 6.1: 1. The fitter takes much longer to do its thing, even to fit a single AND gate takes a lengthy wait. 2. The thing forces me to read HTML reports, which take a long time to generate. And it seems to have to run some stupid java applet. I suppose there may be a way to turn this off, but it was very annoying. 3. If I close the HTML report, it removes all the green checkmarks from the completed processes, and so when I go to configure devices, it has to fit all over again! Because of all this, I have simply ignored 6.1 and have been using 5.2, which works. The question really is, should I bother to try 6.2 ? Good day! -- ____________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA crcarle@sandia.govArticle: 66948
Prabhat Gupta wrote: > Hi, > > I am looking for a DesignCon 2002 Paper: > > "Reuse of Algorithmic Specifications for Synthesis of FPGA and ASIC > Designs" > > Thanks for your help in advance. Have you tried contacting the authors? Reuse of Algorithmic Specifications for Synthesis of FPGA and ASIC Designs Andres Takach, Mentor Graphics Peter Gutberlet, Mentor Graphics Simon Waters, Mentor Graphics JohnArticle: 66949
No I haven't. I do not have their email addresses. The DesignCon 2002 proceedings can be bought from IEC for $95. I need only that paper for non-commercial purpose. I will really appreciate if someone can help me. Prabhat John Williams wrote: > Prabhat Gupta wrote: > >> Hi, >> >> I am looking for a DesignCon 2002 Paper: >> >> "Reuse of Algorithmic Specifications for Synthesis of FPGA and ASIC >> Designs" >> >> Thanks for your help in advance. > > > Have you tried contacting the authors? > > Reuse of Algorithmic Specifications for Synthesis of FPGA and ASIC Designs > Andres Takach, Mentor Graphics > Peter Gutberlet, Mentor Graphics > Simon Waters, Mentor Graphics > > John >
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