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
> These devices seem kind of sensitive. I recently built myself a > ByteBlasterMV cable and a small pcb for an EPM7064S with headers for all > pins and JTAG. The first time I tried it everything seemed to work ok, I > could examine the chip and readout the data(though I thought the chips would > be blank when purchased but it was not). Then I wired everything up to test > the program I wrote and it didnt work anymore. > > Arbitrary As it turned out the chip was not fried. The error was caused by a bad solder joint on the test PCB. The bad solder joint was on the TDO pin which explains the behaviour i saw before. But I guess I should thank you all since this thread got me to look for possible errors one more time. Damn me for making the pads so small :) ArbitraryArticle: 41326
Tim wrote: >>> Brian Davis wrote: >>> in the synthesis of nearly identical circuit constructs: >>> >>> ts_mux <= a_in when sel = "00" else 'Z'; >>> ts_mux <= b_in when sel = "01" else 'Z'; >>> ts_mux <= c_in when sel = "10" else 'Z'; >>> >>> process >>> wait until rising_edge(clk); >>> sig1 <= ts_mux; >>> sig2 <= ts_mux AND '1'; >>> end process; >>> >>> In functional simulation, sig1 will propagate a 'Z', whereas >>> sig2 will propagate an 'X', due to the AND operator resolving >>> the 'Z' to an 'X'. >>> >>> So, following Ken's "match the simulation quirks at any price" >>> synthesis policy, this means that sig1 should have a tristate >>> after the FF, but sig2 should not! <snip> >> >Isn't Brian's example something which, though OK for sim, >should be flagged for synthesis? If this is what is meant, >would it not be a good idea for the code to say so: > > ts_mux <= a_in when sel = "00" else 'Z'; > ts_mux <= b_in when sel = "01" else 'Z'; > ts_mux <= c_in when sel = "10" else 'Z'; > ts_mux <= 'H'; -- synth looks at its technology data base > -- to see if this results in a well-controlled > -- signal into the flop. otherwise, warns/errors. > process > wait until rising_edge(clk); > sig1 <= to_x01(ts_mux); > sig1_enable <= sel="00" or sel="01" sel="10"; > end process; > > final_output <= sig1 when sig1_enable else 'Z'; > That's a pretty good description of what Synplify actually builds at the output pin given the original code. Just to make myself clear, I don't think that's what SHOULD be synthesized from the original code; I was just creating a simple example to show the strange differences in generated logic that would result from a working implementation of this tristate pushthrough feature. > >And "sig2 <= ts_mux AND '1';" just gets a warning from the synth >- "not a supported metaphor > Since the overloaded std_logic_1164 operators know how to resolve signals from 'Z' to 'X', the "sig2 <= ts_mux AND '1'" should resolve the ts_mux signal just as does the "to_x01(ts_mux)" of your example. You bring up another very good point, though: hanging an 'H' driver off the tristate bus would also prevent the input to the flip-flop from ever taking on a 'Z' state. I'll try that out when I get a chance; any wagers on what Synplify does with that one? I'll go with "still builds a tristate output". thanks, BrianArticle: 41327
Before rambling on again, let me distinguish between several
different issues here:
Q1: Does Synplify 7.0.3 let FPGA designers use internal
tristates to build efficient wide mux structures?
Q2: Should a tristate pushthrough "feature" be included
in synthesizers?
Q3: If so, does Synplify implement pushthrough correctly?
My short answers are:
A1: no ( 7.03 / Spartan2 )
A2: NO!!!!!
A3: no
snippets of what Ken wrote :
>
>> Real DFFs don't propagate 'Z's from input to output, but a
>> functional simulation of the standard synthesis template for
>> a DFF will propagate 'Z's under certain conditions.
<snip>
>Any difference between RTL and gate level simulation results
>in users sending us very complicated designs and asking us
>to debug them.
>
Understood.
Just like the "add extra logic around the block RAMs" feature,
you feel you should add extra hardware to "fix" what is really a
simulation/modeling problem.
I respectfully disagree with this policy.
Any such synthesis "features" should be disabled by default,
and if enabled, generate warning messages when they kick in.
>>
>> I firmly believe that this tristate pushthrough behavior
>> is incorrect, as it will lead to serious inconsistencies
>> in the synthesis of nearly identical circuit constructs:
>>
<snip>
>
>Your argument is not really that it is "incorrect" to produce
>a functional match between the RTL and gate level simultion, but
>rather that it is impractical.
>
Perhaps "pathological" would have been a better choice of words,
as in "I firmly believe that this tristate pushthrough behavior
is pathological"
There have always been, and will always be, simulation/synthesis/HW
mismatches; I certainly don't expect Synplify to synthesize a
register that actually propagates 'X's in the real world ( please
tell me that's NOT a feature coming soon in 8.0 ).
Normally, tristates are generated only under specific, well defined
RTL coding guidelines; with this new "feature", minor code changes in
one part of the chip can cause tristates to magically appear and disappear
on output pins many pipeline stages away.
The only time a tristate should be created AFTER a register is
if the designer explicitly codes one there, either with a separate
tristate signal assignent or by assigning 'Z' in one branch of the
control statement that generated the register.
>
> In Aki's test case it looks like we did the transform
> inefficiently. We will fix this.
>
I think this problem (#1) might be a separate issue from the
pushthrough feature ( although it may have been broken by the
new tristate enable analysis code ). If you compile the test
code I posted Friday, even with the syn_keep in place to resolve
the 'Z', the generated hardware shown in HDL analyst (RTL view)
is a logical mux followed by a tristate, instead of a mux
implemented with tristate drivers, even with the tristate-to-mux
conversion threshold set to 1.
>
>It should in practice turn out to cost very little to maintain
>a behavior match in 'Z' propagation.
>
Costs of this "feature":
- toss existing RTL tristate coding guidelines out the window
- can create complex/wide/deep/slow logic for the merged enable
- broke the (formerly working) efficient tristate mux generation
- Synplicity engineering effort to write, debug, and support this
complex 'Z' propagation analysis code
- I suspect the final (i.e. working) implementation of this feature
may have to disable some logic optimizations to function properly
Benefits of this feature:
- for some special cases, there is a minor improvement in pre/post
synthesis simulation matches. ( e.g. a simple RTL register whose
input is driven to 'Z' in simulation will now propagate a 'Z'
instead of an 'X' in post synth simulation. )
>
>In any case we did add a switch in 7.1 to select the old behavior.
>
When will 7.1 be available for download?
I'd also love to read a description of this feature in the
documentation; how on earth are you going to describe the new
RTL coding guidelines for register and tristate inference?
e.g., hypothetical manual entry:
" Tristate Pushthrough in 7.0.3
If an internal tristate bus is connected to an inferred
register, Synplify might sometimes push the tristate though
said register.
If the register is inferred by a simple assignent, Synplify
will push the tristate across the register and any succeeding
registers, until it is resolved or hits an output port; except
in those cases when Synplify's enable optimization decides the
bus is always driven, in which case the tristate will be
completely eliminated from the design.
Registers inferred from an assignment involving a logical or
other operator that resolves the 'Z' will not be subject to
this pushthrough feature, unless Synplify optimizes the logic
performing the resolution out of existence, in which case the
pushthrough might still occur.
"
>
>Thanks for the very clear feedback.
>
Thanks for listening.
Brian
Article: 41328Hi, On Xilinx' App Note XAP333 is an design of a I2C Master/Slave peripheral for a uProcessor, which I've used as basis for designing a slave device. They say on pag 12 that everything (the state machine and associated counters and shift registers are clocked on the falling edge of SCL, 'cause on heavy loaded systems the rise time of the SCL line may be very slow and that is dangerous on a clock a signal, 'cause it can generate noise on it. However, on Philips I2C bus Specification v2.1 Jan-2000, pag 8 they say the data on the SDA line must be stable during the HIGH period of the clock. What would to recommend for an I2C slave on a Xilinx XC4010XL and/or a XCS05XL? Sampling on the falling edge (like Xilinx AppNote does) or sampling on he rising edge (as Philips specification suggests)? Thanks a lot. PS/ I would appreciate your replies also be sent to jaime.aranguren@ieee.orgArticle: 41329
Try this Answers Database. http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=10333 Just for my curiosity, does it make any difference if you replace NET "p_wr_l" LOC = "P77"; with, NET "p_wr_l" LOC = "GCLKPAD1"; in your UCF file? (I sort of doubt it because the problem seems something to do with IBUF and IBUFG.) Kevin Brace (In general, don't respond to me directly, and respond within the newsgroup.)Article: 41330
Hi, 1. You should clariy if your MAX+plus 2 settings are ok. - MAXPLUS2, PROGRAMMER, OPTIONS, HARDWARE SETUP, BYTEBLASTERMV - MAXPLUS2, PROGRAMMER, JTAG, MULTI DEVICE JTAG CHAIN SETUP, DEVICE NAME: EPM7128SLC84, PRGRAMMING FILE: <your_proejct>.pof THe Detect JTAG Chain setup will show you if the device is recognized at all. 2. Do some measurements on TDI, TMS, TCK, TDO according to the appropriate Altera app note. 3. Send an Email to support at altera.com. 4. Try to get a PL-UP-1 university package. Thgis will include an Altera ByteblasterMV, a prinzted circuit board with EPF10K20RC240 and EPM7128SLC84-7 and some other stuff. This one is being sold at 150 bucks, so its quite cheap compared to the 70 bucks you have spend on that download cable which cou could have build for 2 bucks yourself (schematic is available in the ByteBlasterMV datasheet). You can remove the 7128SLC84 with your own part and use the board for programming. Or use the board itself. It has a lot of connectors. For further information you should go to the Altera web page, university program. regards sunnyArticle: 41331
I am wondering how I can activate 5V PCI I/O pads in Altera
FLEX10KE/ACEX1K.
I searched FLEX10KE/ACEX1K datasheet, QII 2.0 Web Edition help, and
FLEX10KE PCI development board manual, but none of them seem to mention
how to configure the I/O pads to support 5V PCI.
Yes, 3.3V PCI I/O is easy since since all I have to do is to select 3.3V
PCI for the I/O pads (I can select that from QII.), and also turn on PCI
Clamping Diode.
For 5V PCI, should I use 3.3V LVTTL I/O pads, and turn off PCI Clamping
Diode, or are there other ways to do it?
Some people who have read my past postings regarding Altera
design tools probably remember me as an Altera nay-sayer, and, yes, I am
still an Altera nay-sayer, and I don't really like QII WE,
LeonardoSpectrum-Altera, or FLEX10KE/ACEX1K compared to Xilinx's similar
offerings (ISE WebPACK, XST, and Spartan-II).
But I do still play around with Altera tools/devices when I feel like,
and I guess right now I am feeling like playing around with Altera's
stuff.
If you didn't like what I said in the past (I still believe they were
fair comments from a Xilinx ISE WebPACK 4.1 user's point of view.), I am
not really going to beg for your advise since I don't actually own a PCI
card with an Altera FPGA (Okay, a LUT-based PLD . . .) on it, so it is
not really important to get my PCI IP core to work on on Altera FPGAs.
(The PCI IP core is doing fine on Insight Electronics Spartan-II PCI
card without any vendor specific optimizations.)
I just thought it will be nice if I can get my design to do well on
FLEX10KE/ACEX1K since that's the last Altera FPGA that supports 5V PCI
(in -1 speed grade).
Thanks,
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 41332[posted and mailed] jaime.aranguren@ieee.org (Jaime Andres Aranguren Cardona) wrote in <14a86f87.0203252127.93e1de@posting.google.com>: >Sampling on the falling edge (like Xilinx AppNote does) or sampling on >he rising edge (as Philips specification suggests)? Sampling on the falling edge should be sufficient and Xilinx already suggest it, why not? I agree with them that the falling edge is much sharper. But remember with SCL low SDA can be changed, but it needs some time to see new data there e.g. PCF8574: t(vd;dat)=SCL LOW to data out valid=3.4us max but t(hd;dat)=data hold time=0 ns, after SCL is going low the data are immediately invalid! (SCL low is defined as <0.3V Vdd, however I would sample SCL at Vdd/2) In the AppNote I read that the bus is working at up to 100kHz, but this is no longer true 400kHz are state of the art, and I have seen devices that operates at 1MHz. Be sure that your slave device can work with at least 400kHz. M.Article: 41333
rickman <spamgoeshere4@yahoo.com> writes: > > IIRC you are doing a C6711 design? I did a C6711, two flash, two > > SDRAM (ith two footprints each to accomodate 64MBit and 256MBit > > devices) a DPRAM and a Flex10KE FPGA (Sorry EPLD :-). It ended up as > > a daisy chain, with series terminators on the FPGA datalines as its > > edges were horrible. The C6711 has (according to TI) been designed > > with slower edges than the previos C6x family so it doens;t need > > terminators as it is a low cost device - and that did seem to be the > > case. > > I am a little confused by what you said. You say that the edge rates on > the C6711 seem to be slower than other C6x chips, and yet you say that > you needed terminators since the edges were horrible. I don't > understand. Did you mean that the C6711B was redesigned? > Sorry, I was unclear! The FPGA edges were horrible so the data lines needed terminating. The address lines (driven only by the DSP) were fine, in fact slower than I would've liked, but they were driving a large number of devices. I don't know about the C6711B, have you beaten an IBIS model out of them yet? The first one I got from TI for the C6711 was great - no driver information at all! Good luck! Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 41334
"emanuel stiebler" <emu@ecubics.com> wrote in message news:3C9F8E16.8DD470F5@ecubics.com... > David Frith wrote: > > > > Hello all > > > > I've just loaded on ISE 4.2i and the first design I ran through gives me an > > error at ngdbuild. This is with exactly the same input files as 4.1i which > > Did you instal the SP1 already ? Probably it goes away ... Installed SP1. No difference. DavidArticle: 41335
Hi,
I am using ispDesignExpert for a Lattice Mach4 design in VHDL. One extremly
annoying thing is that for almost all vhdl modules, I get a compiler
warning:
EDIF2BLIF: Warning: Net VCC is floating and will be removed
and similarly for GND. The warnings do not appear if the code actually
makes use of std_logic '0' or '1', since these obviously get connected to
the VCC or GND nets. The warnings do not do any real harm, but being a
newbie to VHDL I get more than enough warnings and errors as it is - I would
much prefer to get a nice green tick when the code compiles, rather than
these irrelevant warning messages. Does anyone know any tricks to avoid
them, or is it possible to disable them?
Thanks.
--
David Brown
WestControl a.s
Norway
Article: 41336"James Thurley" <newsgroups@NO.SPAM.PLEASE.jamesthurley.com> schrieb: > I'm using a NEF-A-P (http://www.nefdesign.com/) programmer because it's > cheaper than the ByteBlasterMV and works at a good range of voltages. I'm > assuming this is in good working order... > > I'm pretty sure I've got everything connected correctly - I've checked many > times (following the altera diagrams and the report file for my program) - > but when I click on "Detect JTAG Chain Info" in the Altera Stand Alone > Programmer it says it can't detect any devices. > Look at the original Altera Byte-Blaster Design. It has 2 Loopbacks, so that the software is able to detect the kind of adapter used. I dindn't saw them in the NEF-A-P design. Is the software installed corectly? (LPT drivers etc.) I think it is possible for the JTAG pins to be disabled. Once this is the case, you only can enable them with a standard programer. Check another CPLD. DanArticle: 41337
Okay, here is my second Altera FLEX10KE/ACEX1K related question.
Again, if you don't like me because of my past comments about Altera, I
am not going to beg for your advise.
To get an output FF merged into an IOE, I will have to add the
following line in a .esf file.
'pin name' : FAST_OUTPUT_REGISTER = ON;
However, here are some of the problems I got when I synthesized my PCI
IP core.
* Can't pack non-peripheral register <name> to bidir I/O pin <name> --
output register and TRI or OPNDRN primitives cannot both fan-out
* Can't pack non-peripheral register <name> to I/O pin <name> --
register requires a preset in an I/O cell
Looking at the FLEX10KE and ACEX1K datasheet, unlike a Xillinx
Spartan-II IOB, a FLEX10KE/ACEX1K IOE seems to have a feedback path
going back to the LAB, thus it seem like the synthesis tool won't have
to automatically duplicate the FF to get it inside an IOE.
Then, why will get the above problems?
Several months ago when I was dealing with Spartan-II IOB packing rules,
it took me a lot of time and effort to figure it out, and even recently
I had some problems with it (See "XST duplicates unnecessary IOB OE FFs"
if you are interested.), so I am not terribly surprised that I am in the
same situation again.
Thinking about the second error, it seems to me that
FLEX10KE/ACEX1K IOE FF having only an asynchronous Clear, and not an
asynchronous Preset seems to be the reason why I got the error.
QII 2.0 WE's help said there is a synthesis option called "NOT gate
push-back" that supposedly solves this issue, but sounds like a risky
synthesis option.
What are the consequences (side effects) of using this NOT gate
push-back?
In PCI, most control signals like FRAME# or IRDY# are active low, and
their state after reset is logical high (1), so an IOE output FF not
having an asynchronous Preset seems like a major problem.
At least in Spartan-II, I never encountered this problem.
Thanks,
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
Article: 41338A couple of other thaughts: 1) It's pretty inefficient to carry all 32 bits of each word through the sorting logic. How about haveing 16 32bit fifos of equal length to the sorting pipeline, clock the 16 words into them each cycle. Extract the 4 bit key from the word and attatch a 4 bit pointer to the fifo containing the 'parent' word, and just sort this. You would then use the pointers emerging from the sort to reorder the data emerging from the fifos. This would need a lot of logic in itself (or a lot of tristates) but would probably save some. Also, cutting the size of the sort algorthim by a factor of 4 might make it easier to speed up. 2) It's not the case that the 4 bit keys are all unique is it? Probably a daft question. Cheers, Chris SaunterArticle: 41339
Hi! I'm looking for fast clock source (200MHz) for epm7032b, it will produce four phase shifted by 90 degree 50MHz clocks. What oscilator should i use? Crystal oscilators offer ends at 120MHz, i didn't ever use any plls at that high freq's. I'm open for any ideas... BTW how they make lets say: 1GSPS in oscilloscopes (i know that on repetitions but how they get those phase shifts for ADCs? - ECL??) thanx SlawekArticle: 41340
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote: > I personally can live with such an inconvenience, but I cannot live with > inconvenience of the synthesis tool going against my will, and > duplicating an OE FF 32 times. > I think XST has to "trust" the user a little more, and not guess what > the user is trying to do. Your code says that you want a flip-flop which is used as an output enable for your pins. XST has given you a registered output enable for your pins. The output from the synthesis tool is logically correct and matches simulation behaviour. You are doing something unusual and in this case you must specifically ask for it ie by using synthesis primitives. I think you would be very disappointed with the synthesis results if the tool didn't do little things like this. For example, state machine encoding; the tools usually default to one-hot or auto-detect but the most obvious code probably implies a binary encoding. Similarly, no register duplication or buffering which would give significantly worse timing results in some designs. You also depend on the tool for automatic IBUF/OBUF/IOBUF instantiation which saves a lot of time and a lot of messy code. There is no way that the tool can please everyone. It can either be dumb by default (which will suit you in this case but not many other people) or smart. There will always be times when you have to disable the smart behaviour. As long as that is easy, the smart behaviour is the correct default. My only complaint would be that it's often too difficult to disable these optimisations. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 41341
hi all, anyone know how do can I prevent the infer of mult18x18 in Virtex II? I have a resources conflict with Block Ram and I only need to complete the mult in 4 cycle @ 100 mhz. any switch during map or UCF constraint I can use? I am using Synplify pro and ISE4.2 thanks pyngArticle: 41342
Thanks Kevin, Excuse me while I wipe the egg off my face... Hey, I had looked at that page in the Answers Database, but I wasn't sure how to follow the solution (obviously, I'm new to VHDL!), and I wasn't sure if it related to my problem or not, so I posted just before leaving work. So, when I got your post, I decided to try it (guessing if necessary!), and lo and behold, it worked like a charm, first time! So, lesson learned: don't be so damn timid! Thanks again! "Kevin Brace" <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote in message news:a7p6m9$qj7$2@newsreader.mailgate.org... > Try this Answers Database. > > http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID= 1&getPagePath=10333 > > > Just for my curiosity, does it make any difference if you replace > > NET "p_wr_l" LOC = "P77"; > > with, > > NET "p_wr_l" LOC = "GCLKPAD1"; > > > in your UCF file? (I sort of doubt it because the problem seems > something to do with IBUF and IBUFG.) > > > > Kevin Brace (In general, don't respond to me directly, and respond > within the newsgroup.)Article: 41343
Thanks very much for everyones help - I took everything over to uni and had a look at the JTAG outputs, but the strange thing was they all seemed to just be sitting at 5v. I think I may have done something wrong in testing because I wired up an led between TMS and ground and the led wasn't very bright relative to the others, but acording to the osciloscope it was also at a steady 5v which seems to be a contradiction. I'm didn't have enough time to look into this thoroughly though because the labs are shutting down for the holidays - I'll have to wait till next term to try it out again. I did manage to program the chip using their out of system programmer though, so I know the chip is ok and I know at worst I can use that. Thanks again for all the advice, James.Article: 41344
u could use the synplify attribute syn_multstyle = logic. This would prevent Synplify of using the 18x18 multiplier. Information will be forward annotated to ISE thru the ncf.Article: 41345
Hi All , Where can I find information about numerical characteristic of failure rate of Xilinx Óhips(Spartan2, Virtex series)? This information is needed for calculation reliability index of entire device. -- Best regards, Vladislav Vasilenko Hardware engineer. National Technical University of Ukraine mailto:vlad@comsys.ntu-kpi.kiev.uaArticle: 41346
Hi! Is there any idea for multiplying clock in max7000 devices? thanx SlawekArticle: 41347
Can't really tell you how to fix your problem, other than the advice that you should always finish a design/project to completion using the same software before upgrading. I'm still using Foundation 3.3 with ISE 4.1 & 4.2 still in their boxes, and I'm not taking them out till I have finished my project. adrian > > David Frith wrote: > > > > > > Hello all > > > > > > I've just loaded on ISE 4.2i and the first design I ran through gives me > an > > > error at ngdbuild. This is with exactly the same input files as 4.1i > which > > > > Did you instal the SP1 already ? Probably it goes away ... > > Installed SP1. No difference. > > David > >Article: 41348
I looked at various implementations of I2C interface and from what I saw it is indeed better to use the falling edge, since the rising edge is due to a tri-state pulled-up and the falling edge is due to a signal actively driven low. I chose the falling edge in my design. My fast (45MHz) clock is used for edge detection. It is recommended to have an anti-glitch filter on SCL/SDA lines - rising/falling times could be long. 100 KHz+_ no probems. 400KHz did not try yet.
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