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
The Swedes have had such tilting trains (S2000) for many years. I have taken it from Gothenburg to Stockholm 4 years ago, and the Italians have had them so early that they coined the name Pendolino. The Germans tried it with limited success. It provides high speed on an old-fashioned rail bed. Peter Alfke ======================== > From: "Symon" <symon_brewer@hotmail.com> > Newsgroups: comp.arch.fpga > Date: Mon, 26 Apr 2004 14:15:02 -0700 > Subject: Re: transport applications > > Jon, > http://news.bbc.co.uk/1/hi/england/3549809.stm > http://news.bbc.co.uk/1/hi/uk/3315197.stm > Cheers, Syms. > >Article: 69076
Symon, Yes, that is what I was asking whether. Thanks. Can you tell what you were trying to achieve by combining these two beasts in one JTAG chain? I want to be able to use boundary scan equipment to verify connections between the chips in the board manufacturing phase. I am still not sure if it is worth the effort and money considering that I won't get 100% pin coverage... I would be curious to know how many people are actually using Intellitech and similar tools for testing their boards? Sorry if this is OT... Thanks, /Mikhail -- To reply directly: matusov at square peg ca (join the domain name in one word and add a dot before "ca") "Symon" <symon_brewer@hotmail.com> wrote in message news:c6k0bo$clejr$1@ID-212844.news.uni-berlin.de... > Mikhail, > If you mean can you still program the FPGAs over the JTAG then yes, it's OK. > I've done it before with a Virtex II and an Intel StrongArm processor. IIRC > you need a boundary scan discription file for the 3rd party IC to keep > Impact happy. Sorry I can't be more specific, this work was at a previous > company. > Cheers, Syms.Article: 69077
"Jay" <127.0.0.1@127.0.0.1> wrote in message news:KZ5jc.9808$3m2.9400@fe03.usenetserver.com... > In article , mchan wrote: > > > I came across an interesting DLL that does just this. Rather than delay the > > input jittery clock, it uses its own oscillator which should be > > plesiochronous (close in frequency) to the input clock, and relatively free > > of jitter. Phases of this clean clock 60 degrees apart are generated, and > > control logic selects and interpolates different phases together to create > > an output clock that is of the same frequency, and synchronous with the > > input clock. I can dig up a link to the paper if your interested. > > Hi! > > Yes, I'd be interested, could you dig that paper up? > > Jay. > Here's the paper: http://mos.stanford.edu/papers/ss_isscc_97.pdf Cheers, Michael.Article: 69078
> It provides high speed on an old-fashioned rail bed. Why do I want tilting trains? Why not bank the tracks more? Is the problem something like a tight radius of curvature such that a long train would get pulled off the track as it went around the curve? (Maybe a long slow freight runs on the same tracks.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 69079
"arkaitz" <arkagaz@yahoo.com> escribió en el mensaje
news:c1408b8c.0404260712.444a63e6@posting.google.com...
> Hi,
>
> I have some problems when using two clock domains in my design.
>
hadnt you posted this problem before?
> My main clock works at a frequency of 60 Mhz. The clock port is routed
> to the input port of the internal DLL which provides two clock
> sources, one of the same frequency (60 Mhz) and the other of 20Mhz.
>
> There is a rising edge detector FF excited with 20 Mhz clock
>
> re_detect:
> block is
> signal aux : std_logic;
> begin
> process( rst, clk_20 )
> begin
> if ( rst = '1' ) then
> aux <= '0';
> elsif ( clk_20 = '1' and clk_20'event ) then
> aux <= input;
> end if;
> end process;
>
> re_edge <= not(aux) and input;
>
> Note: the input is synchronized to avoid glitches and metastability.
>
what do you mean by "synchronized"? to what? besides "input" should be
stable before (and after) the clock edge, they shouldnt change at the same
time (if that's what you meant with "synchronised")
and i would have thought that a glitch is what you're getting with those "0
ps" pulses
> Then I have another FF whose set and reset are separate conditions
> that is
> excited with 60 Mhz clock.
>
> process ( rst, clk_60 )
> begin
> if ( rst = '1' ) then
> out <= '0';
> elsif ( clk_60'event and clk = '1' ) then
> if ( input = '1' ) then
> out <= '1';
> end if;
> if ( re_edge = '1' ) then
> out <= '0';
> end if;
> end if;
> end process;
>
> I have simulated functionally the design with Modelsim 5.6f and I see
> that "out" signal doesn´t become low when "re_edge" is active. Note
> that the if clauses are writen in such way so that the reset condition
> has the biggest priority.
>
you could write it otherwise, like
elsif ( clk_60'event and clk = '1' ) then
if ( re_edge = '1') then
out <= '0';
elsif ( input = '1' ) then
out <= '1';
end if;
end if;
> This might be because the "re_edge" signal is a 0 ps wide pulse, I
> mean is asserted and dessaserted in the same simulation step and in
> the same time with the rising edge of the clock signal.
>
dont you think you should correct that? do you think that's a good sign?
besides that's completely normal from your "re_edge <= not aux and input"
even on real logic that pulse wouldnt be large, how large do you want it to
be? and even then it should arrive a bit later than the clk60 edge, so you'd
probably miss it anyway
> I don't know certainly why, but I believe that it can be because I use
> the DLL.
what, the 0 ps pulse is due to the DLL? or "out" not going low?
>I have created the same design using a clock divider instead
> of a DLL and it works but there are several differences in the
> functional simulation:
>
> - "re_edge" signal is a clk_20 period wide signal instead of a glitch
> - "aux" signal is asserted 1 clk_20 period later than the "input"
> signal
>
and what do you want?
> Anybody any suggestion?
>
why are you synchronizing the reset of the second FF with a clock that's
running slower than this FF clock?
if what you want is to reset your second FF on a rising_edge of input, then
i wouldnt do its reset "synchronous"
why dont you use a "digital oneshot" clocked by the fastest clock (so that
your output stays low or high just for one cycle), that could be a FSM that
would wait for a high (that'd be the rising_edge of input) value of input,
and then wait for it to become low to start waiting again.
anyway, i know shit, what is what you're trying to do anyway?
> Thanks in advance,
>
dont worry, i dont think i know better than you :)
> Arkaitz
> -------------------------------
> Ikerlan
> Electronics Area
> Pº J. M. Arizmendiarrieta, 2
> 20500 Arrasate (Gipuzkoa)
> -------------------------------
Article: 69080"Narcis Nadal" <nnadal@terra.es> escribió en el mensaje news:unLic.4700406$uj6.16108118@telenews.teleline.es... > Yes, we have recently designed and produced here in Catalonia some 192x64 > LED displays with 16 gray levels EN 50155 compliant for the TGV > Barcelona-Madrid. Those displays have a Xilinx XCS05 industrial grade as a > coprocessor. > did you mean "intensity" levels? wasnt TGV a French train? i thought in Spain you had AVE or something > Regards > > Narcis Nadal > "Jacek Mocki" <jacekmocki@poczta.onet.pl> escribió en el mensaje > news:c6anq7$7r$1@news.onet.pl... > Does anyone know some examples of using CPLD or FPGA devices in railways > equipment? > > Regards > > Jacek > >Article: 69081
Hi Marc, Thanks for your input. After further experimentation I found that LUT based addressable SR was only being inferred for SR of length 16 bits or less. I managed to build a 128 bit addressable SR by cascading 8 SRLC16E primitives and using MUXF5,F6 and F7 to get the addressed bit. But this makes my HDL source Xilinx specific. JoshArticle: 69082
And then Dave wrote: > I've purchased the Memec V2Pro board and Xilinx EDK. Can I use my > Parallel Cable III, or is the IV required? Thanks. > > -Dave I had this problem, and contacted Memec tech support. The fix they suggested, is dissconnecting Vcc (red wire) from JTAG and connect directly into 3.3V on JP29. This works for me. Remis -- ************************************************ To reply, remove >.spam< and >.fake<Article: 69083
And then Martin Maurer wrote: > Hello, > > i want to create a special UART with a FIFO (at least 64 Bytes deep, > perhaps bigger). > Can someone tell me, how a FIFO can be implemented in hardware ? Is is > "simply" an array of bytes, with two counters: one for filling it in and > one for reading out ? Or is there a better approach ? > > At the moment i have only knowledge in ABEL with XILINX CPLD (XC95) > series. Is it the right way to use a CPLD (perhaps a big one, because of > the amount of storage cells needed only for the FIFO) ? Or does a FPGA (i > read they have RAM inside, where i hopefully can put my FIFO in ?) fit > better this job ? What XILINX chip (because of already available > environment) do you recommend for this and why ? > > Regards and thanks for helping, > > Martin Check out the Picoblaze source code by Ken Chapman, which is available for free from Xilinx web site. The source included really nice and compact UART with 16-byte FIFO. Remis -- ************************************************ To reply, remove >.spam< and >.fake<Article: 69084
The OP stated that he was trying to infer a DYNAMIC shift register, which implies an SRL16.
Otherwise, he needs a register file with a mux, which is both bulky and slow. The synthesis tools
are notoriously inconsistent and picky about the style needed for this structure to be inferred as
an SRL16, and I've seen different tools wind up with different results, even when going between
versions of the same tool. In order to get the dynamic shift register reliably it unfortunately
needs to be instantiated. The tools are much better with static shift registers (ones whos length
does not change in the operating circuit), but still care is needed to make sure a flip-flop is
inserted after each SRL16. The synthesis tools that recognize SRL16's generally do now put a
flip-flop after a single SRL16. They are not so good at putting a flip-flop after every SRL16 when
several are cascaded together to get delays of more than 17 clocks. As long as you have the
flip-flops after each SRL, and they are properly placed (which implies that they do not use the
reset), the SRL16's will not be the limiting factor in clock speed. Leave those registers off, and
you'll severely limit the clocking. BTW, don't attempt to use both the dynamic and Q15 outputs of
the same SRL16 in a high performance design. The Q15 output is just as slow as the Y output if it
does not connect through a flip-flop in the same slice.
john jakson wrote:
>
> > Marc
>
> I had the opposite problem in Verilog, when I had a deep pipeline more
> than 4b deep I think, with no inter logic, it did roll into a wide
> srl16 and halved my clock in doing so. There is an option in the XST
> preferences display for turning this feature on/off. I think if I can
> tune the srl with an extra true FF at the end it will be useable at
> full speed, just the timing for srls is slower on the output bit.
> There's also some appnotes on it and there is some template code for
> these if you look in the right place.
>
> I would suggest not coding them directly unless you really know that
> they must be used. If you suddenly decide to insert logic into the
> middle, you will have to redo that.
>
> regards
>
> johnjakson_usa_com
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 69085
It also limits the clock speed because of the slow clock to out when using
either the Y or Q15 outputs without a register.
Josh Graham wrote:
> Hi Marc,
> Thanks for your input. After further experimentation I found that LUT
> based addressable SR was only being inferred for SR of length 16 bits
> or less. I managed to build a 128 bit addressable SR by cascading 8
> SRLC16E primitives and using MUXF5,F6 and F7 to get the addressed bit.
> But this makes my HDL source Xilinx specific.
> Josh
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 69086On Mon, 26 Apr 2004 19:44:04 -0500, hmurray@suespammers.org (Hal Murray) wrote: >> It provides high speed on an old-fashioned rail bed. > >Why do I want tilting trains? Why not bank the tracks more? Legacy tracks do not have the appropriate bank. (Telephone system analogy: we put expensive modems (ADSL, etc.) on the end of old twisted pair lines, since it's really expensive to replace the stuff that's already in the ground.) Regards, Allan.Article: 69087
Hi, I am using QuartusII 3.0. I setup a tsu requirement on some input pins and quartus did a P&R and said it could not meet the tsu by 0.5ns on only one of the paths. So I relaxed my tsu by about 1ns on all pins and did an incremental fitting. Now Quartus came back and said it could not meet timing on about 15 paths by 1.5ns. Why is this? Is there anyway of adding more predictibility in the P&R of Quartus? Thanks & regards tushitArticle: 69088
Hello, I need to buy one (1) unit of XC4010XL-09-PC84. If anyone is willing to sell me the part, please, write an email to langemauricio (at) yahoo.com.ar (replace "(at)" with "@" ) Thank you very much. Mauricio LangeArticle: 69089
Hi Mikhail, We did exactly as you describe, i.e. we "want[ed] to be able to use boundary scan equipment to verify connections between the chips in the board manufacturing phase."! All the parts were BGAs so it was a good way to check connections. Also we used the JTAG on the processor to program its flash memory with boot loader code after the boards were populated. Finally, we used just one chain because it needed a smaller connector than multiple chains. As to whether boundary scan's worth it or not, that depends on your volume, yeild, rework cost for completed units, etc. Cheers, Syms. "MM" <mbmsv@yahoo.com> wrote in message news:c6k2fv$cmssq$1@ID-204311.news.uni-berlin.de... > Symon, > > Yes, that is what I was asking whether. Thanks. Can you tell what you were > trying to achieve by combining these two beasts in one JTAG chain? I want to > be able to use boundary scan equipment to verify connections between the > chips in the board manufacturing phase. I am still not sure if it is worth > the effort and money considering that I won't get 100% pin coverage... I > would be curious to know how many people are actually using Intellitech and > similar tools for testing their boards? Sorry if this is OT... > > Thanks, > /Mikhail >Article: 69090
I have a Xilinx Spartan IIE device and it has built in block rams that I would like to use for effectively a ROM design. All the documentation that I can find that Xilinx provides seems to be rather old (2000-2001) and thus doesn't work on the current tools (Webpack 6.2). Does anyone know how to specifiy block ram initialization values in verilog using Webpack 6.2? Thanks, ArlenArticle: 69091
Hi,
include re_edge in sensitivity list.
Article: 69092We use Corelis tools to verify ball-to-ball connectivity. Every board that we manufacture utilizes the JTAG chain to test as much of the board that is possible. Our chains involve Xilinx FPGA's and many other types of JTAG-able devices. Bob "MM" <mbmsv@yahoo.com> wrote in message news:c6k2fv$cmssq$1@ID-204311.news.uni-berlin.de... > Symon, > > Yes, that is what I was asking whether. Thanks. Can you tell what you were > trying to achieve by combining these two beasts in one JTAG chain? I want to > be able to use boundary scan equipment to verify connections between the > chips in the board manufacturing phase. I am still not sure if it is worth > the effort and money considering that I won't get 100% pin coverage... I > would be curious to know how many people are actually using Intellitech and > similar tools for testing their boards? Sorry if this is OT... > > Thanks, > /Mikhail > > -- > To reply directly: > matusov at square peg ca > (join the domain name in one word and add a dot before "ca") > > > > "Symon" <symon_brewer@hotmail.com> wrote in message > news:c6k0bo$clejr$1@ID-212844.news.uni-berlin.de... > > Mikhail, > > If you mean can you still program the FPGAs over the JTAG then yes, it's > OK. > > I've done it before with a Virtex II and an Intel StrongArm processor. > IIRC > > you need a boundary scan discription file for the 3rd party IC to keep > > Impact happy. Sorry I can't be more specific, this work was at a previous > > company. > > Cheers, Syms. > >Article: 69093
Hi,
I want to simulate a FMF VHDL SRAM model.
In the model itself there is the following declarations:
LIBRARY IEEE; USE IEEE.std_logic_1164.ALL;
USE IEEE.VITAL_timing.ALL;
USE IEEE.VITAL_primitives.ALL;
LIBRARY FMF; USE FMF.gen_utils.ALL;
USE FMF.conversions.ALL;
When I try to compile the model with Modelsim I get the following error message:
# ** Error: (vcom-19) Failed to access library 'fmf' at "fmf".
What can I do about that? Where exactly can I get the library on the FMF site and
how do I have to include it in Modelsim?
Thanks
Article: 69094Hi, when trying to access the data register of a device I must first perform a cast on the register address: example: int * data_register = (int *) 0xFFFF0000; Can somebody explain me why the cast is needed ? Thx, T.Article: 69095
>when trying to access the data register of a device I must first >perform a cast on the register address: > >example: > >int * data_register = (int *) 0xFFFF0000; > >Can somebody explain me why the cast is needed ? Find a friendly software geek and get them to give you a lesson in type checking. Assuming int x; Roughly, it's so the compiler knows that data_register is a pointer to an int rather than an int. So you need to write x = *data_register rather than x = data_register Having the compiler check for that sort of mixup catches a huge fraction of simple programming bugs. (They are often a pain to track down with traditional debugging methods.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 69096
Hal Murray <hmurray@suespammers.org> wrote: : > It provides high speed on an old-fashioned rail bed. : Why do I want tilting trains? Why not bank the tracks more? Because then, when an emergency braking has to be exercised, the train would fall over... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 69097
Hi Paris,
First of all, thanks for answering to my message.
I'll try to answer to all of your questions.
> hadnt you posted this problem before?
Yes and no. The post I wrote before had to do a lot with this one but
now I think that the problem comes from another source.
> what do you mean by "synchronized"? to what? besides "input" should be
> stable before (and after) the clock edge, they shouldnt change at the same
> time (if that's what you meant with "synchronised")
> and i would have thought that a glitch is what you're getting with those "0
> ps" pulses
The "input" signal is an asynchronous input port and it must be
synched before I use in my design, just to avoid metastability and
glitches. Even if its asynchronous it's active during several clock
hundreds of clock cycles. Here you are the synch:
entity top
port (
...
in : in std_logic;
...
);
end top;
architecture arch of top is
...
signal input : std_logic;
signal i_filter : std_logic_vector(1 downto 0);
...
begin
process ( rst, clk )
begin
if ( rst = '1' ) then
i_filter <= (others => '0');
elsif ( clk'event and clk = '1' ) then
i_filter(0) <= in;
i_filter(1) <= i_filter(0);
end if;
end process;
input <= i_filter(1);
> you could write it otherwise, like
>
> elsif ( clk_60'event and clk = '1' ) then
> if ( re_edge = '1') then
> out <= '0';
> elsif ( input = '1' ) then
> out <= '1';
> end if;
> end if;
yes, that's true, but the result would be the same.
> dont you think you should correct that? do you think that's a good sign?
> besides that's completely normal from your "re_edge <= not aux and input"
> even on real logic that pulse wouldnt be large, how large do you want it to
> be? and even then it should arrive a bit later than the clk60 edge, so you'd
> probably miss it anyway
just a clock period wide to allow to use it as a clock enable signal.
I have done used this code several time and it has always worked.
> > I don't know certainly why, but I believe that it can be because I use
> > the DLL.
> what, the 0 ps pulse is due to the DLL? or "out" not going low?
both, because one comes from the other, I mean, the "out" doesn't go
low because the rising edge signal is not detected correctly.
> and what do you want?
just to know if somebody has ever got any trouble using two different
clock domains and when both clocks are provided by the DLL.
My reflexion: it might work in physically but I would like ensure with
functional simulation before implementing the design.
> why are you synchronizing the reset of the second FF with a clock that's
> running slower than this FF clock?
Because that's requirement of my design. I know that I could do with
some clock enables but the DLL might be necessary in order to improve
the required max. frequency.
> if what you want is to reset your second FF on a rising_edge of input, then
> i wouldnt do its reset "synchronous"
do you mean using asynchronous signals in a syncronous design? I don't
think that'd be a great idea.
> why dont you use a "digital oneshot" clocked by the fastest clock (so that
> your output stays low or high just for one cycle), that could be a FSM that
> would wait for a high (that'd be the rising_edge of input) value of input,
> and then wait for it to become low to start waiting again.
That's another posibility but it might use more resources than what
I've done.
Thanks a lot for your patience,
Arkaitz
-------------------------------
Ikerlan
Electronics Area
Pº J. M. Arizmendiarrieta, 2
20500 Arrasate (Gipuzkoa)
-------------------------------
Article: 69098Anand P Paralkar <anandp@sasken.nospam.com> wrote in message news:<408CA66F.7FAA0E6A@sasken.nospam.com>... > Hi, > > I was talking to an "expert" in synthesis and he mentioned that there is > > a lot of difference between a synthesizable RTL code for a FPGA and a > synthesizable RTL code for an ASIC. > > Is this true? > > If so, could you please point the significant differences between the > two and what causes these differences. > > Thanks, > Anand Hi anand, I have worked on FPGA to ASIC migration.First we proved our design on Xilinx FPGA's.We used pipelining, variable & signals.During ASIC migration there were lot of warnings generated,so we replaced all variables with signals.Basically design must be very structural and synchronous.There must not be nesting of "if statements".Use clock gating to reduce power.Our design need almost 40% changes just to improve area and reduce power. Regards, Raghavendra.SArticle: 69099
Hi, does someone know if Alliance provide VHDL simulation models for their synchronous SRAMs? Thanks in advance. Rgds
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