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
Nope, this one had individual NE-2 bulbs in plug -in counter modules. Each counter
module was one digit, with a tube plug on the bottom. I think there were four tubes
on the back. Each module was about 1.5"w x 4"h x 4"d, and was a closed metal box
except the tubes sticking out the back.
Georg Acher wrote:
> In article <3C486EF6.69A05003@andraka.com>,
> Ray Andraka <ray@andraka.com> writes:
>
> |> > There was a time before Nixie tubes?
> |>
> |> Yes, I had a frequency counter years ago that had bars with numbered windows.
> |> Behind each was a neon bulb which would light up the correct digit. An
> |> additional neon bulb lit up behind the range (Hz, kHz), and there was one
> |> between each column to act as a decimal point. The display for a 59.703 Hz
> |> input would look something like this:
>
> These funny tubes were decatrons, a huge neon bulb with 10 electrodes and a
> sophisticated "shift"-mechanism for the discharge.
>
> A nice description can be found here:
>
> http://mypage.bluewin.ch/sagnell/id14.htm
>
> --
> Georg Acher, acher@in.tum.de
> http://www.in.tum.de/~acher/
> "Oh no, not again !" The bowl of petunias
--
--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: 38626I have a 16MHz clock to play with and thought of simply synchronizing the shift register and state machine with this clock and look for transistion of the slow clock ... It indeed looks like the better solution so far... thanks Ray ... Ray Andraka wrote: > I assume your local clock (the free running one you mention) is quite a bit > higher than your shift clock. That being the case, a better solution is to > transfer the incoming clock and data to your master clock domain, then detect > edges on your incoming clock. Usually on a sync serial line, the data > transitons are arranged to fall halfway between the active edges on the > clocks. That buys some resistance to slop. > > To do this, I like to use a toggle register clocked by your incoming clock. > Delay the data by a register to match the delay on the clock to keep it more or > less centered. The output from the toggle register goes through a synchronizing > flip-flop clocked by the master clock, then to a simple state machine that > generates a 1 clock wide pulse each time the synchronized toggle signal changes > state. That becomes pulse becomes the shift pulse for your shift register, > which is now in the master clock domain. > > Joe wrote: > > > I have a simple 77 bit parallel to serial shift register w/ an > > asynchronous reset_n and a synchronous load: > > --------------- > > p2s: process(CLK, RESET_N) > > begin > > > > if RESET_N = '0' then > > SHIFT_REG <= (others => '0'); > > elsif (CLK'event and CLK = '1') then > > if LOAD = '1' then > > SHIFT_REG <= SHIFT_REG_IN; > > elsif SHIFT_EN = '1' then > > SHIFT_REG(76 downto 1) <= SHIFT_REG(75 downto 0); > > SHIFT_REG(0) <= '0'; > > end if; > > end if; > > end process; > > > > SOUT <= SHIFT_REG(76); > > > > ----------------- > > > > The p2s register works fine; however, I will only be receiving across > > the interface 77 clocks! So how do I load the register initially? Is it > > permissable simply to gate in an extra clock(from the on board free > > running clock) for loading purposes? > > > > Such as : > > > > CLK <= CLK_77 or (CLK_1MHZ and ONE_PERIOD); > > > > Where ONE_PERIOD is high asserting pulse at the appropriate LOAD time. > > > > The reason I ask is this -- I do not like to put anything in front of > > the clock of a long shift register in order to limit any problems with > > clock skew between registers. The incoming 77 clocks(named CLK_77) are > > 1MHz clock periods. > > > > Thanks in advance.... > > -- > --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, 1759Article: 38627
IIRC, there was a knob to set the gate period. The decimal and range lamps depended
on both the gate and range knobs. I'm pretty sure it was a simple gate. I wish I
could find a picture of the thing. I can't even remember who made it now.
Jim Granville wrote:
> Georg Acher wrote:
> >
> > In article <3C486EF6.69A05003@andraka.com>,
> > Ray Andraka <ray@andraka.com> writes:
> >
> > |> > There was a time before Nixie tubes?
> > |>
> > |> Yes, I had a frequency counter years ago that had bars with numbered windows.
> > |> Behind each was a neon bulb which would light up the correct digit. An
> > |> additional neon bulb lit up behind the range (Hz, kHz), and there was one
> > |> between each column to act as a decimal point. The display for a 59.703 Hz
> > |> input would look something like this:
> >
> > These funny tubes were decatrons, a huge neon bulb with 10 electrodes and a
> > sophisticated "shift"-mechanism for the discharge.
> >
> > A nice description can be found here:
> >
> > http://mypage.bluewin.ch/sagnell/id14.htm
>
> Impressive - these things could count and display at the same time,
> with _one_ element :-)
>
> Be a good student exercise, get them to make a similar thing in todays
> devices. Some license would have to be given on the charge-push detail
> that ensured it 'hopped' in only one direction.
>
> Ray - To display 59.703Hz did this use a 1000 second gate, ( 16.6
> minutes )
> or did they have reciprocal freqency counting solved :-)
>
> -jg
--
--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: 38628
Kevin Goodsell wrote:
> Hi. I know very little about FPGAs or using HDLs, so please bare with
^^^^
You wan't me to remove my clothing!? I think not. Sorry, I couldn't bear it.
Anyway, I don't think your problem is really the code, rather (at least from
what I gather from your brief description), I suspect your "clock" is coming
from a switch closure, in which case you just learned about switch bounce
the hard way. A mechanical switch contact actually opens and closes
many times over a period of a few milliseconds when it is actuated and
released. The logic detects each of these bounces as a separate open/close
cycle so you wind up getting many clocks when you thought you had only
one. You need to add a debounce circuit to present a clean clock.
>
> me. I'm trying to get the following module (in Verilog) to work with a
> Spartan 2 FPGA using the Xilinx Webpack software:
>
> module shift_reg(in, clk, out);
> input in, clk;
> output [0:8] out;
>
> reg [0:8] data;
>
> assign out = data;
>
> always @(posedge clk)
> begin
> data <= #1 {data[1:8], in};
> /* data[0] <= #1 data[1];
> data[1] <= #1 data[2];
> data[2] <= #1 data[3];
> data[3] <= #1 data[4];
> data[4] <= #1 data[5];
> data[5] <= #1 data[6];
> data[6] <= #1 data[7];
> data[7] <= #1 data[8];
> data[8] <= #1 in; */
> end
> endmodule
>
> The part that is commented out is another thing that I've tried. I've
> also tried many variations on the assignments (blocking, non-blocking,
> with/without delays inside and outside the assignments, and so on). I
> am nearly convinced that the problem is not the code, but has
> something to do with the way the software is handling the clk signal.
>
> First, let me explain what I'm seeing when I test it. It seems that on
> the rising edge of clk, the "in" signal is read into every bit of
> data, rather than only data[8]. Occasionally, the lower bits seem to
> fail to register a change, though.
>
> In my user constraints file, if I try to assign clk to a normal I/O
> pin, I get the following error:
>
> ERROR:MapLib:93 - Illegal LOC on symbol "clk" (pad signal=clk) or
> BUFGP symbol "clk_BUFGP" (output signal=clk_BUFGP), IPAD-IBUFG should
> only be LOCed to GCLKIOB site.
>
> I don't know what this means, or whether it has anything to do with
> the module not working. For the record, here's my .ucf file:
>
> #NET "clk" LOC = "P112"; # this line causes the error
> NET "in" LOC = "P110";
> NET "out<0>" LOC = "P3";
> NET "out<1>" LOC = "P5";
> NET "out<2>" LOC = "P7";
> NET "out<3>" LOC = "P9";
> NET "out<4>" LOC = "P14";
> NET "out<5>" LOC = "P16";
> NET "out<6>" LOC = "P18";
> NET "out<7>" LOC = "P21";
> NET "out<8>" LOC = "P23";
>
> Thanks ahead of time for any help.
>
> -Kevin
--
--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: 38629
You of course are correct. It is the two flops in the same domain the I floorplan to
keep the interconnect short. Not sure what I was thinking here.
Philip Freidin wrote:
> On Wed, 16 Jan 2002 22:29:20 GMT, Ray Andraka <ray@andraka.com> wrote:
> >The other case, where clocks are async to each other, it is still a good idea to
> >constrain the path because you want to minimize the transport time from the
> >flip-flop in one domain to the flip-flop in the other domain
>
> Up to here, I agree.
>
> >so as to maximize the metastability settle time.
>
> But not to this.
>
> Since the clocks are async to each other, constraining the delay between
> the source ff Q and the dest ff D (the data path) will in no way affect
> the metastability of the system. The dest FF is the one that can go
> metastable, and the delay to its D pin does not affect the situation
> that the source FF can change at arbitrary times relative to the dest
> FFs clock time. Playing with resolution time occurs between the dest FF,
> and the logic that it drives, which should also be in the dest FFs
> clock domain.
>
> >A from:to constraint is needed here so that the
> >tools do this. So even though intuition might indicate that a timing constraint
> >is not needed here since you *will* go metastable at some time, the truth is a
> >constraint is vital here to keep from eating up your metastability resolution
> >time with propagation delay.
>
> Sorry, disagree as explained above, and in gory detail below.
>
> >In this case, the skew doesn't matter much, so it
> >probably doesn't hurt to include it (it is meaningless anyway). I usually
> >floorplan the flops on each side of a crossing like this so that they are in
> >adjacent slices within a CLB. That alone doesn't guarantee use of the fast
> >connect, but it at least makes it possible.
>
> If you divide up the cycle time of the dest FF in to an arbitrary number
> of small time slices (N), the probability of any transition event occuring
> in any specific time slice is 1/N. Of these time slices, some meet the
> setup and hold requirements, and some violate setup or hold. When you
> change the delay from the source FF to the dest FF, you change which
> time slice a specific transition will occur in, but the probabilities
> don't change, it is still 1/N for each slice, and therefore, metastability
> is not affected.
>
> Given the above, time specs for these inter-clock domain signals is still
> useful. What you are constraining is the worst case arrival time for the
> synchronizer (starting at the dest FF) to start resolving a transition,
> but the granularity is dest clock period.
>
> Here's a contrived example:
>
> Src clock 20MHz (50ns)
> Dest clock 25MHz (40ns)
>
> Src FF clk-to-out 1ns
> Dest FF setup time 2ns
> Dest FF hold time 0ns
>
> Assume 2 stage synchronizer
>
> Path delay 30ns
>
> Scenario 1: just in time
>
> Src changes, 31ns later arrives at dest, 1.1 ns before dest clock
> Dest FF sees the transition OK
> 40 ns later the second stage dest ff outputs the changed data
>
> time to get the transition cleanly into the dest domain is
> 31+1.1+40 ns = 72.1 ns
>
> Scenario 2: just missed it
>
> Src changes, 31ns later arrives at dest, 2 ns after dest clock
> Dest FF does not see the transition
> 40 ns later, Dest FF sees the transition OK
> 40 ns later the second stage dest ff outputs the changed data
>
> time to get the transition cleanly into the dest domain is
> 31+38+40 nS = 109 ns
>
> Scenario 3: resolved metastable
>
> Src changes, 31ns later arrives at dest, 0.5 ns before dest clock
> Dest FF goes metastable
> 10 ns later dest FF resolves metastable
> 30 ns later the second stage dest ff outputs the changed data
>
> time to get the transition cleanly into the dest domain is
> 31+.5+40 ns = 71.5 ns
>
> If we assume that the 40 ns is sufficient to resolve all the
> metastables we care about ( :-) ) , then in the limit, for the
> above example we know we can get the signal from src to dest
> in somewhere between 71 and 111 nS.
>
> Positive and negative skew on the clock to the source FF has
> NO affect on these calculations. (the 50nS cycle time does
> not appear in any of the calculations)
>
> Positive skew on the dest FF clock (late arrival of the clock)
> will detract from the resolution time within the synchronizer,
> but this is not the path we are talking about. It will also
> add to to effective delay, increasing the 71 and 111 lower
> and upper bounds. Negative skew has the opposite effect.
>
> If we didn't constrain the the src to dest path, and the
> router made it a 60 ns path, we would still have lower and
> upper bounds ( 101 and 141 ), but the probability of
> metastability would be the same.
>
> So ....... I do put constraints on these paths, but is to
> bound the time it takes the signal to get to the
> synchronizer.
>
> Philip Freidin
>
> Philip Freidin
> Fliptronics
--
--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: 38630Can anyone send me information, and/or example code of the partial reconfiguration API using JBits?Article: 38631
how do i implement my thinking? >K have an initial value,when one condition(n==8) meets ,k will subtract 1.otherwise keeps.k's initial value depends on a 32bit register .so it is variable.Article: 38632
By the way,when k equal 0,the 32bit register only will change.i will procedd other according k value change.Article: 38633
Peter Alfke <peter.alfke@xilinx.com> wrote: > [-- text/plain, encoding 7bit, 27 lines --] > If the two clocks are unrelated, you WILL have set-up time violations, sooner or > later even metastability problems. Not if the destination flip-flop is only clock enabled some time (several cycles) after the source signal is stable. regards Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 38634
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<a29rnb$vjtkk$1@ID-84877.news.dfncis.de>... > "Kevin Neilson" <kevin_neilson@removethis-yahoo.com> schrieb im Newsbeitrag > news:gXY18.4397$HM2.40256@rwcrnsc52.ops.asp.att.net... > > > > There was a time before Nixie tubes? > > Yes, just a couple of years after the extinction of the dinosaurs ;-)) The bar type (Beckman EPUT meters) still surface at NASA surplus sales. I think they dredge the river bottom to find them.Article: 38635
View at www.pearlone.comArticle: 38636
how do i implement my thinking? *********************************** K have an initial value,when one condition(n==8) meets ,k will subtract 1.otherwise keeps.k's initial value depends on a 32bit register .so it is variable. when k equal 0,the 32bit register only will change.i will procedd other according k value change. eg:k=24.when (n==8) meets,it subtract 1.it equals 23.othersize 24.next time,when (n==8) meets.it subtract 1.it equals 22.othersize 23.it will stops forever until it equals 0.if it equals 0,the 32bit register value will change.at this time, k will have a new initial value.so forever . my code is: reg [5:0] k; > integer n; > > always @(posedge Clock or negedge Rst_N ) > begin > if (!Rst_N) > k<=0; > else > begin > k<=A;//(initial value (variable)) > if(n==8) //meet one condition > k<=k-1;//subtract 1 > else > k<=k; //keep > end > end > when i simulate with modelsim,it was wrong. verilog is unlike C.it can be given a difference value in two difference always clause.when synthesised,it will report more than one driver error. can you advise me?or how to implement ?Article: 38637
>> If the two clocks are unrelated, you WILL have set-up time violations, sooner or >> later even metastability problems. > >Not if the destination flip-flop is only clock enabled some time (several >cycles) after the source signal is stable. That doesn't avoid the metastability problem. It just pushes it over to the logic that decided when to do the clock enable. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 38638
On Sat, 19 Jan 2002 23:10:13 GMT, Ray Andraka <ray@andraka.com> wrote: > > >Kevin Goodsell wrote: > >> Hi. I know very little about FPGAs or using HDLs, so please bare with > > >^^^^ >You wan't me to remove my clothing!? I think not. Sorry, I couldn't bear it. >Anyway, I don't think your problem is really the code, rather (at least from >what I gather from your brief description), I suspect your "clock" is coming >from a switch closure, in which case you just learned about switch bounce >the hard way. A mechanical switch contact actually opens and closes >many times over a period of a few milliseconds when it is actuated and >released. The logic detects each of these bounces as a separate open/close >cycle so you wind up getting many clocks when you thought you had only >one. You need to add a debounce circuit to present a clean clock. Good suggestion, but incorrect. I'm using a microprocessor's output ports to program it. Actually, I'm familiar with switch bounce, and it *was* the problem (at least part of it) in a completely different situation at work a few weeks ago. -KevinArticle: 38639
On Fri, 18 Jan 2002 17:08:27 -0700, Brian Philofsky
<brian.philofsky@xilinx.com> wrote:
>
>Some comments below about the code and error message.
>
>Kevin Goodsell wrote:
>
>> Hi. I know very little about FPGAs or using HDLs, so please bare with
>> me. I'm trying to get the following module (in Verilog) to work with a
>> Spartan 2 FPGA using the Xilinx Webpack software:
>>
>> module shift_reg(in, clk, out);
>> input in, clk;
>> output [0:8] out;
>
>"in" and "out" are key words in VHDL. As a general rule of thumb, do not
>use VHDL key words in Verilog. Although this is most likely not the cause
>of your problems, it could save you grief later.
>
>I also suggest if you have the flexibility to generally use little-endian
>notation, [8:0] not [0:8]. For most cases, it works fine either way but
>there are some legacy issues with using this notation and because of that,
>when I have the choice, I use little endian. Sometimes processors or
>other IP lock you into one notation and in that case, I would not swim
>upstream.
>
Thanks for the suggestions.
>
>> reg [0:8] data;
>>
>> assign out = data;
>>
>> always @(posedge clk)
>> begin
>> data <= #1 {data[1:8], in};
>
>In general, do not put delays in synthesizable code. Synthesizers ignore
>the delays and could lead to mis-match between synthesis and simulation.
>
I suspected that synthesizers ignored delays, but that's one of many
details that was never mentioned in the crappy (IMHO) Verilog book I
learned from.
>
>
>
>>
>> /* data[0] <= #1 data[1];
>> data[1] <= #1 data[2];
>> data[2] <= #1 data[3];
>> data[3] <= #1 data[4];
>> data[4] <= #1 data[5];
>> data[5] <= #1 data[6];
>> data[6] <= #1 data[7];
>> data[7] <= #1 data[8];
>> data[8] <= #1 in; */
>> end
>> endmodule
>>
>> The part that is commented out is another thing that I've tried. I've
>> also tried many variations on the assignments (blocking, non-blocking,
>> with/without delays inside and outside the assignments, and so on). I
>> am nearly convinced that the problem is not the code, but has
>> something to do with the way the software is handling the clk signal.
>
>As a general rule, I usually use blocking for combinatorial functions and
>non-blocking for registered signals. To be honest, if you don't specify
>delays, it usually does not make a big difference which you use.
>
Okay...
>
>
>> First, let me explain what I'm seeing when I test it. It seems that on
>> the rising edge of clk, the "in" signal is read into every bit of
>> data, rather than only data[8]. Occasionally, the lower bits seem to
>> fail to register a change, though.
>
>Not sure about that. Code looks OK to me. Where do you see this behavior
>(simulator or on the board)? Did you perform any timing analysis or
>timing simulation?
>
Simulation is fine, last time I checked. Wouldn't hurt to test it
again, though. I didn't do a timing analysis, and I've only done a
standard simulation (AFAIK) if that's different from a timing
simulation. I don't know anything about those, so I'll have to look
into them.
>
>
>> In my user constraints file, if I try to assign clk to a normal I/O
>> pin, I get the following error:
>>
>> ERROR:MapLib:93 - Illegal LOC on symbol "clk" (pad signal=clk) or
>> BUFGP symbol "clk_BUFGP" (output signal=clk_BUFGP), IPAD-IBUFG should
>> only be LOCed to GCLKIOB site.
>
>The synthesis tool will defaultly put you on an IBUFG which locks you to
>certain I/O clock pins. This is the best thing to do if you have this
>flexibility. If your board is made and you no longer have the flexibility
>to use the dedicated clock pins, I suggest you instantiatite a BUFG
>between your clock port and clock signal in your code. This will result
>in a slightly longer clock delay than you would have if you use the
>dedicated pin however still get you on the global clock network and thus
>minimze clock skew, which is one of your greatest eminmies in synchronous
>design.
>
I have all the flexibility I need, but this is mostly Greek to me. It
sounds like you are saying that I should go ahead and use a GCLKIOB
because it can't hurt and might help. That is fine.
Thanks for the help.
-Kevin
Article: 38640Hey all, I'm a student at the university of waterloo and we've just gotten some new altera excalibur nios boards. I was trying to do some work at home using the web edition of the quartus 2 software. At this point, I suddenly realize, I'm missing some files. Mainly the nios development kit (specifically the excalibur nios megawizard plug ins). I can't seem to find this kit anywhere on their site. I found an update, but it requires version 1.0 or something like that. I'm assuming it's only available on CD when u buy their kit. Would anyone here happen to have this kit and would not object to my obtaining of it :). Just as a general question. Why would they be so protective of this software? I mean, the software is useless you have the actual board isn't it? Thanks all for any response, BolisArticle: 38641
oops, I forgot to mention, we use the 20KE chip. regards Bolis "Bolis" <bogusemail@hotmail.com> wrote in message news:Tru28.19235$_D2.5068767@news20.bellglobal.com... > Hey all, > > I'm a student at the university of waterloo and we've just gotten some new > altera excalibur nios boards. I was trying to do some work at home using > the web edition of the quartus 2 software. At this point, I suddenly > realize, I'm missing some files. Mainly the nios development kit > (specifically the excalibur nios megawizard plug ins). > > I can't seem to find this kit anywhere on their site. I found an update, > but it requires version 1.0 or something like that. I'm assuming it's only > available on CD when u buy their kit. Would anyone here happen to have this > kit and would not object to my obtaining of it :). > > Just as a general question. Why would they be so protective of this > software? I mean, the software is useless you have the actual board isn't > it? > > Thanks all for any response, > > Bolis > >Article: 38642
> I'm a student at the university of waterloo and we've just gotten some new > altera excalibur nios boards. I was trying to do some work at home using > the web edition of the quartus 2 software. At this point, I suddenly > realize, I'm missing some files. Mainly the nios development kit > (specifically the excalibur nios megawizard plug ins). You're missing a couple of CDs - the Nios HDK and Nios SDK which install all the relevant gubbins and link it in nicely with Quartus. Your university should be able to let you have them (note that for the latest version you need the 1.1 update on CD plus the 1.1.1 download) Hope this helps, JamesArticle: 38643
Please can anyone from Altera comment on the availability of the Nios v2 softcore processor? Many Thanks, JamesArticle: 38644
hi all. i have a design in verilog and only some small sections need floorplanning. the problem is the design is a little unstable and so small pieces of code are changing as the spec is changing. each time i change, i need to refloorplan and it is getting a little time consuming. my design flow is synplicity for synthesis and xilinx foundation for place and route. seems synplicity changes the net names randomly each time i synthesize, even if i try and lock down the modules with the syn_hier = hard attribute. i heard that i might be able to accomplish what i want if i used the exemplar tool, since they can do a module by module synthesis, but i fear that the performance is not as high as synplicity's. strut911Article: 38645
does anyone know how to do bottom up synthesis with synplicity? also, is there an easier way to apply the syn_hier attribute such as with a wildcard (doesn't seem to work). i have many modules in my design and when i am debugging post-synthesis, i like to have all my module interfaces intact. thanks. strut911Article: 38646
I also tried to get some information over the internet and eventually they sent me a hyperlink which crashed my IE5.5. My local supplier is also in the dark. End of December ? Which year 2001 or 2002? Victor "James Srinivasan" <James_Srinivasan@nospam.yahoo.com> wrote in message news:a2e28c$m0a$1@pegasus.csx.cam.ac.uk... > Please can anyone from Altera comment on the availability of the Nios v2 > softcore processor? > > Many Thanks, > > James > >Article: 38647
>> Please can anyone from Altera comment on the availability of the Nios v2 >> softcore processor? > I also tried to get some information over the internet and eventually they > sent me a hyperlink which crashed my IE5.5. My local supplier is also in > the dark. > End of December ? Which year 2001 or 2002? I was told December/January (presumably 2001/2002!) but haven't heard anything yet. Fingers crossed...Article: 38648
While using DLLs in FPGAs, is it necessary to use IBUFG and BUFG? Are there any applications of DLL without using BUFG and IBUFG?Article: 38649
Can we use DLL for reducing o-chip skew?If we can, please tell me the methods.
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