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
"Ken Mac" <aeu96186@yahoo.co.uk> schrieb im Newsbeitrag news:a5o4kv$spj$1@dennis.cc.strath.ac.uk... > > I am not using a PLL outside (I don't think - would the DAC have one?). Could be. > clk33 comes in on a pin and is fed through a DLL to the design. > clk425 also comes in on a pin and is fed through a DLL to the design. ^^^^^^^^^^^^ ^this is rarely possible. A DLL works only on clock signals with frequencies >25 MHz. And they must be continous, no gapped clock or similar tricks. -- MfG FalkArticle: 40201
Luigi wrote: > assigning 500 pins with my mouse wouldn't have been a good way to use > my time, especially if I have to floorplan more than one time... So why not use your text editor on the .csf file like Jean-Baptiste suggested? -- Mike TreselerArticle: 40202
hello, I'm using Xilnx Foundation Tool(4.1i) to map some of my designs. In the process I want to simulate the "time_sim.vhd" file that is generated in the timing simulation phase of the (Implementation) flow engine. Can anyone suggest me a method (apart from using Modelsim Simlator to do the same)? thanks. regards PraveenArticle: 40203
Hi, Thanks. It seems I was looking at delays which involve the input/output pin delays too. When I registered my inputs and outputs and measured the register-to-register delay, the delay is much lesser (<20ns). I put 2 multipliers in series one after another. The second one takes an input from the previous multiplier output. This gives a delay of about 10ns. These definitely make more sense. For people with Xilinx software experience (ISE Webpack).... Where can I get a trace report ? The synthesis report says that accurate timing information is available in a trace report produced after place and route. I see some reports after place and route, but none are called trace reports. Any ideas ?? Thanks. Prashant "Peter Ormsby" <faepete.deletethis@mediaone.net> wrote in message news:<f9Df8.10278$Or3.1089192@typhoon.mn.ipsvc.net>... > Prashant <prashantj@usa.net> wrote in message > news:ea62e09.0202281345.1467d3c2@posting.google.com... > > If anything, the 20K1500E is going to be slower than the 20K160E. However, > you should be able to get much faster speeds out of your 20K160E than you > are currently seeing. > > Make sure that your inputs and outputs are registered. It takes a > relatively long time for a signal to go between the pins and the FPGA > routing structure, so it's helpful to move the inputs into a register before > running them though the multiplier and then registering the multiplier > outputs before running them off the chip. > > Once you have the inputs and outputs registered, you should be able to get a > multiplier working about 50MHz with no pipeline stages or over 110 MHz with > two stages in a 20K160E. You can use the Megawizard to create a pipelined > multiplier without having to figure out the partial products implementation > yourself. > > Let me know if this doesn't help. > > -Pete-Article: 40204
jerry1111 wrote: > > What to do when I have negative reset (as usual with uP) > and I connect reset signal to fpga, but internal ffs wants to > get positive reset (f.e. MAX3000). When I place inverter > and all ffs are feed from inverted signal I got messages > 'non global signal usage may result'. Some (older) CPLDs do not support either global polarity. Atmel ATF1502AS is close to MAX3000, and does have either Global Reset choice. <paste> jerry > And what means that message 'signal usage may not be global' or sth like that > is generated? > Are there any disadvantages other than some delays in clock propagation? > Can I safely ignore this message? (Part runs OK with this message) or there > are 'hidden' things happenig when such message is generated? It means product terms are being used to generate the required polarity. This adds a slight delay, but a RESET is not normally 'delay paranoid'. More important, is there is less resource for more usefull logic. Al Williams wrote: > > True, but what if you want to get tricky and have one flip flop latch > on the rising edge and another latch on the falling edge? This seems > to work, but it does whine about the clock not being global. > > I haven't tried it, but I was wondering if you could invert the clock > and then feed it through a global buffer (assuming you haven't used > all the global buffers). Don't know if that'd work or not. I know this works on the ATF1502AS. Dual edge clock work is getting more common, but even the venerable i2c bus has this. -jgArticle: 40205
Couldn't you try out one of the many free processor cores as well. You could probably synthesise this for your Nios board. e.g. the Leon sparc processor I thought the Nios was extremely good value considering the wealth of tools, board, software etc. Paul "jerry1111" <jerry1111@wp.pl> wrote in message news:a5oj6f$mjh$1@news.tpi.pl... > Hello, > > I want to buy Altera's softcore uP. > Which one: Nios-based or Arm-based? > Any suggestions? > Before spending money for development tools I'd like > to know the good and bad news for it. > > Is it possible to move from Nios to Arm-based without > spending lot of money for Arm option (already having > Nios purchased)? > > Thanks > > jerry > >Article: 40206
O.K. as I wrote: "double-buffering would help", and that's what you are doing. Sorry for my insulting assumptions ;-) Ray already mentioned that 155 MHz would be o.k. if you floorplan accorcingly. Are you using Virtex-II? You probably know that you can read out data at a different width, if that helps you. In your case, you can read out 16 bits wide, although you wrote 32 bits wide. Provided the speed is right. Greetings Peter Alfke, Xilinx Applications "H.L" wrote: > Hi Peter, thanks for your reply > I was confident of this method's effectiveness but now I am worried :)) . I > have already done a timing analysis in the paper and also the simulation > waveforms seem promising. > I didnt understand what do you mean when telling me that one of my words > arrives early and the other one late. The transmitter sends to my FPGA an > external clock (thats the 155MHz clock), a valid signal (1 bit indicating > the transmission time period) and of course the 16-bit words that I have to > store. Every clock period (~6 ns) I have available in my ports one 16-bit > word, I register two sequential words from the in port to a 32-bit register > (31->16 the first incoming word, 15->0 the second one). Then , in another > 32-bit register I register (2 nd time) the 32-bit word I just "made" which > are the BRAM data_in. All the above operations are in a process that has in > its sensitivity list the 155 clock. I write to the BRAM at 77MHz using the > incoming clock divide by 2 using a DLL. BRAM input signals are assigned in > the falling edge of the 77MHz clock so as to be before the rising edge (of > the same clock) where the BRAM samples them. The write operations are in > another process with the slow clock in its sensitivity list. > The timing waveforms of the simulation are the same with the timing analysis > in paper but does this is a valid hardware design technique? > Thanks for your time and help! > > Best Regards, > Harris > > p.s: thats a small part of my design. I use DLL because other parts need > them (BUS_MUX e.t.c) , I tried to implement my whole design @ 155 MHz and I > got many timing errors (floorplanning managed to reduce them but still lot > of work to be done) > > "Peter Alfke" <peter.alfke@xilinx.com> wrote in message > news:3C7E621F.1E77A244@xilinx.com... > > I suggest you grab pencil and paper and do a clock-by-clock timing > analysis. You > > will find that your clock-speed reduction buys you nothing, unless you > also > > double-buffer the data. > > One of your words arrives nice and early, the other one late. However you > clock > > the BRAM, one of the two words has the same old short set-up time... > > Double-buffering would help. But Ray has mentioned some neat tricks to > avoid the > > long set-up time of the control inputs. > > > > I will get back with more constructive notes. "Gotta run" > > > > Peter Alfke > > =================== > > "H.L" wrote: > > > > > Hello all, > > > > > > I have a module that accepts 16 bit words at 155MHz and I want to store > then > > > in an 128x32 BRAM. I am going to use a DLL (in a Virtex-E FPGA) to > divide by > > > 2 the 155MHz clock as this frequency seems to be pretty high to write in > the > > > BRAM. So far I think 2 processes are enough to do my job, one operating > @ > > > 155MHz to accept the 16-bit data and store them in a 32-bit register and > the > > > another one @ 75MHz to write the content of the 32-bit register in the > BRAM. > > > I am thinking to assign the BRAM's signals > (ENABLE,WRITE,ADDRESS,DATA_IN) in > > > the falling edge of the 75MHz clock, the main reason for this is the > setup > > > time of the BRAMs signals (in this way the address,data are 6 ns before > next > > > rising edge of the clock where BRAM samples its inputs). My question now > :) > > > , if one process uses the falling edge of one clock does this causes > > > problems to other processes in the design , e.g to processes that use a > > > different clock or to processes using the rising edge of the same > clock? > > > > > > Best Regards, > > > Harris. > >Article: 40207
That is good that you already got the specification.
Although, I sounded like PCI Hardware & Software isn't too important,
it gives more waveform examples than the specification, so you might
find it helpful from time to time.
However, this book is not a book a designer should try to read through
the whole thing to learn PCI bus because that will take enormous amount
of time (I tried to do so about three years ago, but got discouraged,
and quit.).
Instead, read the section relevant to the part you are implementing at
the time.
Regardless, the book is only a bus protocol book, so the devils
will be in the implementation, especially so in FPGAs (At least, Xilinx
claims that at LogiCORE PCI website. I have never even touched ASIC
tools, so I don't have a way to independently verify that claim, but it
is likely true.).
As long as the levels of 4-input LUT for unregistered signal paths are
low (3 levels if the routing distance is short, 1 level or 2 levels if
the routing distance is long.) meeting Tsu < 7ns for 33MHz PCI should
not be a major issue for Spartan-II-5 class FPGA.
Kevin Brace (Don't respond to me directly, respond within the
newsgroup.)
Matthias Scheerer wrote:
>
> Hi Kevin,
>
> I forgot to say that we already have the PCI Spec, which is actually the
> basis of our development. Due to your comment I think PCI Hardware and
> Software will be right for us.
>
> Thanks for the comprehensive answer.
>
> Matthias
>
Article: 40208
--------------48BC095289FFAC626EAB9B38
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Here is a simple and robust handshake circuit.
http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm
Peter Alfke, Xilinx Applications
rickman wrote:
> I would continue to use the 425 kHz clock to clock the DAC. I would
> then use the rising edge of this clock to latch the data out to the DAC
> data pins. I belive the 425enable signal can just tell the 33 MHz
> Process B to load new data into the previous register.
>
> But I actually would have done your processes a little differently. One
> of the nice things about the memory in a Spartan II is that they are
> dual ported with independent clocks. Unless you need a control signal
> (like Empty or Full) passing between the two domains, you could easily
> move data without the messy metastability issues.
>
> Actually, you HAVE to have some controls passing between the two clock
> domains because there has to be a counter that increments when you put
> data in and decrements when you take data out. But this is very easy
> and is essentially like the syncing you did on the 425EN signal. But it
> would eliminate the Process B logic. The wide difference in clock
> speeds makes this a much simpler problem. I assume that you are writing
> blocks of data to the FIFO? If you are responding to each word that is
> read out to the DAC, then you don't need the FIFO, right?
>
> Ken Mac wrote:
> >
> > Phil,
> >
> > Forgot to mention that the DAC is fed the 425kHz clock via a pin of my
> > Spartan-II.
> >
> > The DAC uses the negative edges of the 425kHz clock to take data from
> > process C.
> >
> > Process C uses the positive edges of the 425kHz clock to place data on the
> > serial data pin for the DAC and the negative edges then drive the DAC.
> >
> > My DAC output now seems to be irregular - what signal should I use to clock
> > my DAC now?
> >
> > Thanks again,
> >
> > Ken
> >
> > > > Process A: Runs at 33MHz to fill a 16 location FIFO with 8-bit data
> > > > samples and then keep it full.
> > > > Process B: Runs at 33MHz to take data from the FIFO when told to and
> > > > supply it to process C via a register.
> > > > Process C: Runs at 425kHz and sends FIFO 8-bit data samples to a DAC
> > > > bit-serially then asks process B for next piece of data.
> > >
> > > > Process A is fed with data via a Visual C++ app (the Spartan-II is
> > mounted
> > > > on a PCI board) which is synchronised with the FPGA using an interrupt
> > pin
> > > > that the FPGA can assert and the C++ can read.
> > > >
> > > > I have used this system for many designs with no trouble (none of them
> > had
> > > > multiple clock domains however). The problem here is that the design is
> > > > getting stuck in state for no apparent reason! (i.e. the C++ hangs
> > waiting
> > > > for the interrupt pin!).
> > >
> > > Sounds to me like you have a problem crossing clock domains.
> > >
> > >
> > > > The system works for a random number of samples (between 28 and 33 it
> > seems)
> > > > and then gets stuck in state. This is very strange because it means that
> > my
> > > > protocols do work.
> > >
> > > Not strange at all. Suppose we have two registers in one clock domain
> > sampling
> > > a signal from the other clock domain. If both get the same value for the
> > next
> > > clock, the logic works. If only one gets the value, the logic hangs.
> > >
> > >
> > > > The weird thing is that I put a piece of debug code in another state to
> > send
> > > > a signal out to a pin to probe, I ran the flow again to get a bitstream
> > and
> > > > the system ran perfectly for all 75001 samples I am using! The debug
> > code
> > > > was "Debug <= '1'".
> > >
> > > Different placement, different routing, different timing, different odds
> > of
> > > failure. Might work well at 25C, and fail like above at 28C.
> > >
> > > > Then I enabled clock DLLs using the BUFGDLL component and it hangs
> > again!
> > >
> > > Different timing, different odds of failure.
> > >
> > >
> > > > Previously, I had it working perfectly using the clock DLLs but without
> > a
> > > > FIFO (i.e. 1 sample at a time from C++ to FPGA to DAC) but I got some
> > > > stutters hence I introduced the FIFO.
> > > >
> > > > In that design I also had hanging problems but after I rejigged my
> > protocol
> > > > in my VHDL state machines it worked perfectly.
> > > >
> > > > It seems that seemingly random changes of VHDL make or break the system.
> > I
> > > > guess it must be to do with my 2 different clock rates but that is the
> > way
> > > > it has to be.
> > > >
> > > > I am at a loss - anyone any ideas?
> > >
> > > First, sync the 425KHz to 33 MHz, then edge detect, and then use the edge
> > > detected clock 425 for a clock enable for process C. Code fragments:
> > >
> > > process(clk33) begin
> > > if rising_edge(clk33) then
> > > synslow <= clk425;
> > > synslow2 <= synslow;
> > > synslow3 <= synslow2;
> > > en425 <= synslow2 and not synslow3;
> > > end if;
> > > end process;
> > >
> > > processc:
> > > process(clk33) begin -- was (clk425)
> > > if rising_edge(clk33)
> > > if en425 = '1' then -- was rising_edge(clk425)
> > > ....
> > >
> > > The reason this (hopefully!) will solve your problem is that almost all
> > logic
> > > will be running on a single clock. While there is a chance that synslow
> > will
> > > not correctly clock in clk425 on rising or falling edge ("go metastable"),
> > > synslow2 is much less likely to fail (As mean time between failures >> age
> > of
> > > universe), and en425 even less so.
> > >
> > > Also, you could synchronize all control signals between the two processes.
> > More
> > > complex.
> > >
> > >
> > > --
> > > Phil Hays
>
> --
>
> 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 FAX
Article: 40209
Thanks for giving me a reason to try "-k" again. Unfortunately the
results are still a little inconclusive.
-k 4 1766 LUTs
-k 5 1766 LUTs
-k 6 1766 LUTs
-k 7 crash back to OS
-k 8 crash back to OS
I'm still running 3.3.08i.
Regards
acher@in.tum.de (Georg Acher) wrote in message news:<a5m848$d46$1@sunsystem5.informatik.tu-muenchen.de>...
> In article <d049f91b.0202281030.206aeb6b@posting.google.com>,
> kayrock66@yahoo.com (Jay) writes:
> |> I'm trying to pitch that my client use Synopsys Design Compiler
> |> instead of an FPGA specific synthesizer from another vendor since his
> |> Xilinx Vertex 2 FPGA is a proto for a standard cell part. The clock
> |> speed isn't important, verification of the tool flow and design
> |> database is.
> |>
> |> The problem I'm running into is that the Design Compiler output uses
> |> almost 200% the LUTs compared to the purpose built FPGA synthesizer.
> |> So the logic will no longer fit the proto board.
> |>
> |> Mini Example:
> |> Design compiler: 1760 LUTS
> |> FPGA synthesizer: 824 LUTS
> |>
> |> Design compiler synthesizes to cells like AND2, OR2, AND4, etc whereas
> |> the FPGA specific tool maps directly to special LUTs custom made for
> |> the logic required like LUT_AB5A and LUT_67FE, etc. Now I figured the
> |> Xilinx mapper would be smart enough to "map" the Design Compiler AND2,
> |> OR2, etc, into more compact LUT_ABCD and LUT_6534 type cells but just
> |> seems to be doing a 1 for one map with no optimization.
> |>
> |> It appears that Xilinx did not write the mapper optimization (option
> |> -oe) for the recent products Vertex E/2 an Spartan 2 in effect giving
> |> up support for Design Compiler.
> |>
> |> Can any one else comment on this? It seems crazy that I can't use the
> |> old man of sythesis (Design Compiler) at $100k seat anymore.
>
> My last experiences with DC are only on the 4k-Series (now I'm using
> fpga_compiler2 for Spartan2), but maybe this helps:
>
> "map -help spartan2" shows among others:
>
> -k 4|5|6 Function size for covering combinational logic. If -k
> is not specified, the default is -k 4. This gives the
> best balance of runtime to quality of results. Using
> 5 or 6 can give superior results at the expense of
> runtime.
>
> So try to use -k 6, this can make design much smaller (and faster...)
>
> Have you used the usual tweaks in DC, like
> "compile -boundary_optimization -map_effort high" and
> "compile -map_effort high -ungroup_all" afterwards?
>
> Are you sure that the reset net is replaced by the STARTUP-symbol and removed
> in the design ("disconnect_net reset -all")?
Article: 40210
"Peter Alfke" <peter.alfke@xilinx.com> wrote:
> click on
> http://support.xilinx.com/support/techxclusives/fifo-techX18.htm
> The best Gray-code counter implementation actually starts with a
> binary counter and converts it, bit by bit, to Gray. Therefore, you
> can subtract the two binary count values, and then clean up the
> result with techniques described in my another paper
> http://support.xilinx.com/support/techxclusives/MovingData-techX16.htm
Good idea. If you're writing VHDL, the VHDL below might give you some
ideas.
Paul Butler
library ieee;
use ieee.std_logic_1164.all;
use work.GrayPack.all;
entity GrayCounter is
port(
signal Clock : in std_logic;
signal Reset : in boolean;
signal DirectionUp : in boolean;
signal CounterVal : out Gray
);
end GrayCounter;
architecture RTL of GrayCounter is
signal CurrentCount : Gray(CounterVal'range);
begin
Process(Clock, Reset)
begin
if Reset then
CurrentCount <= (others => '0');
elsif rising_edge(Clock) then
if DirectionUp then
CurrentCount <= CurrentCount + 1;
else
CurrentCount <= CurrentCount - 1;
end if;
end if;
end process;
CounterVal <= CurrentCount;
end RTL;
--synthesis translate_off
entity test_GrayCounter is
end test_GrayCounter;
library ieee;
use ieee.std_logic_1164.all;
use work.GrayPack.all;
architecture behave of test_GrayCounter is
component GrayCounter
port(
signal Clock : in std_logic;
signal Reset : in boolean;
signal DirectionUp : in boolean;
signal CounterVal : out Gray
);
end component;
signal Clock : std_logic;
signal Reset : boolean;
signal DirectionUp : boolean;
signal CounterVal : Gray(7 downto 0);
signal StopClock : boolean := false;
begin
Stimulus:
Process
begin
Reset <= true, false after 1 ns;
DirectionUp <= true, false after 5 us;
StopClock <= false, true after 10 us;
while not StopClock loop
Clock <= '0';
wait for 50 ns;
Clock <= '1';
wait for 50 ns;
end loop;
wait;
end process;
DUT: GrayCounter
port map(
Clock => Clock,
Reset => Reset,
DirectionUp => DirectionUp,
CounterVal => CounterVal
);
end behave;
-----------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
package GrayPack is
type Gray is array (natural range<>) of std_ulogic;
function To_Gray (arg : in unsigned) return Gray ;
function To_unsigned (arg : in Gray) return unsigned ;
function "+"(l : in Gray; r : in Gray) return Gray ;
function "+"(l : in Gray; r : in integer) return Gray ;
function "+"(l : in integer; r : in Gray) return Gray ;
function "+"(l : in Gray; r : in unsigned) return Gray ;
function "+"(l : in unsigned; r : in Gray) return Gray ;
function "-"(l : in Gray; r : in Gray) return Gray ;
function "-"(l : in Gray; r : in integer) return Gray ;
function "-"(l : in integer; r : in Gray) return Gray ;
function "-"(l : in Gray; r : in unsigned) return Gray ;
function "-"(l : in unsigned; r : in Gray) return Gray ;
function "-"(l : in Gray; r : in Gray) return unsigned ;
function "-"(l : in Gray; r : in integer) return unsigned ;
function "-"(l : in integer; r : in Gray) return unsigned ;
function "-"(l : in Gray; r : in unsigned) return unsigned ;
function "-"(l : in unsigned; r : in Gray) return unsigned ;
end GrayPack;
package body GrayPack is
function To_Gray (arg : in unsigned) return Gray is
variable result : Gray(arg'range);
begin
result := (others => '0');
result(result'high) := arg(arg'high);
for i in result'high-1 downto result'low loop
result(i) := arg(i) xor arg(i+1);
end loop;
return result;
end To_Gray;
function To_unsigned (arg : in Gray) return unsigned is
variable result : unsigned(arg'range);
begin
result(result'high) := arg(arg'high);
for i in result'high-1 downto result'low loop
result(i) := result(i+1) xor arg(i);
end loop;
return result;
end To_unsigned;
function "+"(l : in Gray; r : in Gray) return Gray is
begin
return To_Gray(To_unsigned(l) + To_unsigned(r));
end "+";
function "+"(l : in Gray; r : in integer) return Gray is
begin
return To_Gray(To_unsigned(l) + r);
end "+";
function "+"(l : in integer; r : in Gray) return Gray is
begin
return To_Gray(l + To_unsigned(r));
end "+";
function "+"(l : in Gray; r : in unsigned) return Gray is
begin
return To_Gray(To_unsigned(l) + r);
end "+";
function "+"(l : in unsigned; r : in Gray) return Gray is
begin
return To_Gray(l + To_unsigned(r));
end "+";
function "-"(l : in Gray; r : in Gray) return Gray is
begin
return To_Gray(To_unsigned(l) - To_unsigned(r));
end "-";
function "-"(l : in Gray; r : in integer) return Gray is
begin
return To_Gray(To_unsigned(l) - r);
end "-";
function "-"(l : in integer; r : in Gray) return Gray is
begin
return To_Gray(l - To_unsigned(r));
end "-";
function "-"(l : in Gray; r : in unsigned) return Gray is
begin
return To_Gray(To_unsigned(l) - r);
end "-";
function "-"(l : in unsigned; r : in Gray) return Gray is
begin
return To_Gray(l - To_unsigned(r));
end "-";
function "-"(l : in Gray; r : in Gray) return unsigned is
begin
return (To_unsigned(l)-To_unsigned(r));
end "-";
function "-"(l : in Gray; r : in integer) return unsigned is
begin
return (To_unsigned(l)-r);
end "-";
function "-"(l : in integer; r : in Gray) return unsigned is
begin
return (l-To_unsigned(r));
end "-";
function "-"(l : in Gray; r : in unsigned) return unsigned is
begin
return (To_unsigned(l)-r);
end "-";
function "-"(l : in unsigned; r : in Gray) return unsigned is
begin
return (l-To_unsigned(r));
end "-";
end GrayPack;
Article: 40211I stated that the DCMs need a 25MHz reference. I read that the system has 44kHz. I was suggesting using the parallel to an analog PLL rather than the DPLLs you see in USB implementations which require significant timing content in the signal the clock is derived from. A phase error detector is emulated by a counter. The 'filtering' is done with shifts and accumulators to mimic the analog filters. The VCO is approximated with a phase accumulator that can leverage the DCMs and global clock muxes to give better jitter characteristics than with a high frequency clock alone. The approach I tried to suggest goes into digital frequency synthesis with the closed-loop approach of an Analog PLL. A system can be designed without abrupt changes in frequency and with other characteristics favorable to analog PLLs without the noise issues inherent in the analog system. My apologies if implementing an analog PLL in the digital realm is too much of a deviation from the "classical" DPLL to effectively communicate the concept. - John_H Ray Andraka wrote: > you are the second to mention the Xilinx DLLs/DCMs. Unfortunately, they are > of no use here since the input clock is only 44 KHz, and even the desired > output is less than half the minimum frequency for those blocks. As for the > DPLL, it is not really a direct port from an analog PLL, there are usually no > filters per se. Instead, the 'filtering' is done by the counters.Article: 40212
The Excaliber ARM implimentation is hardware - a physical unit as part of the APEX chip, not a soft core. Its peripherals are soft, of course. The NIOS, being a soft core, can be used in any Altera chip with the resources (6000 series on up), or even more than once per chip if you wish. Jim Horn (Haven't used NIOS yet but preparing to - nice devel. kit!)Article: 40213
Luigi wrote: > > rjshaw@iprimus.com.au (russell) wrote in message news:<c3771dbf.0202260036.edc1b91@posting.google.com>... > > >............... > > > boring interface of the "Assignment organizer". I cannot assign 500 > > > pins clicking with my mouse! > > > > Yes (in quartus2), open the node-finder, select "pins unassigned", > > Named "*", then click "Start" to list all the pins. > > > > Now open "current assignments" floor-plan, and display the external > > package view. Now just drag and drop the pins from the node-finder > > window to the pins in the floor-plan window. Maxplus2 could do this, > > so any version of quartus probably would too. > > Ah, ok... when I said "I cannot assign 500 pins clicking with my > mouse"... I missed the mouse bit. I thought you meant avoiding keyboard entry.Article: 40214
In article <d049f91b.0203011520.2aa59f8d@posting.google.com>,
kayrock66@yahoo.com (Jay) writes:
|> Thanks for giving me a reason to try "-k" again. Unfortunately the
|> results are still a little inconclusive.
|> -k 4 1766 LUTs
|> -k 5 1766 LUTs
|> -k 6 1766 LUTs
|> -k 7 crash back to OS
|> -k 8 crash back to OS
|>
|> I'm still running 3.3.08i.
Hm, can you try to switch off DC's LUT-mapping? For the 4000-series it was
something like
"set_attribute find(design,"*") "xnfout_write_map_symbols" -type boolean FALSE".
Or maybe I'm mixing that up with fpga_compiler... so long ago...
--
Georg Acher, acher@in.tum.de
http://www.in.tum.de/~acher/
"Oh no, not again !" The bowl of petunias
Article: 40215Have you tried google image search? Type in "xilinx virtex", click on the second image "[ More results from www.chipworks.com ] ", and there is a Virtex II. Higher res would be nice, maybe you already found this one. Ryan "Nicholas Weaver" <nweaver@CSUA.Berkeley.EDU> wrote in message news:a5ohvj$1drt$1@agate.berkeley.edu... > Does anyone have a nice hi-res photo of a Xilinx Virtex CLB or general > die? Google has failed me. > > thanks. > > -- > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 40216
jerry1111 <jerry1111@wp.pl> wrote in message news:a5oj6f$mjh$1@news.tpi.pl... > Hello, > > I want to buy Altera's softcore uP. > Which one: Nios-based or Arm-based? Here's the scoop on Altera's Excalibur... Nios is a soft-core processor that can be implemented in any SRAM-based Altera device SINCE the Flex 6000 devices (since the Flex 6000 devices don't have any RAM blocks, it can't implement the required processor registers). That means that a Nios processor can be targetted at Acex 1K, Flex 10K, Apex 20K/E/C, Apex II, Mercury, Stratix, and any new family introduced in the future. Once you've purchased the Nios development kit, you can use Nios in any number of products you create in any Altera device you select with no royalties or additional costs. The Excalibur ARM device is a hard processor core. The devices are Apex 20KE parts married to a processor "stripe" that contains the ARM core (plus cache memories), an interupt controller, a watchdog timer, an SDRAM controller, timers, a UART, an expansion bus interface (for external SRAM, Flash, etc), an ARM debug trace module, and a bunch of SRAM and dual-port SRAM (quantity varies with device size but ranges from 32KBytes SRAM and 16 KBytes of dual-port up to 256Kbytes SRAM and 128KBytes of dual-port). All of these peripherals are HARD IP created in dedicated silicon. This allows the ARM processor to be alive at power-up before the FPGA part of the device is configured. The ARM stripe has the capability of controlling the configuration of the FPGA, if you desire. Since the ARM processor is a standard ARM922T core, all third-party ARM development tools (compilers. linkers, etc) will work with this device. Note that the two Excalibur solutiuons are not exclusive of each other - you can easily instantiate one or more Nios cores in the programmable portion of the Excalibur ARM devices. In general, the Nios processor is targetted to solutions where you might use a microcontroller or an "embedded" processor while the ARM is the higher performance option. Note that due to Nios's ability to create custom instructions and to support multiple simultaneous bus masters (for concurrent DMA, etc), you can get performance far beyond what one might otherwise expect from an 50-100 MHz processor. -Pete-Article: 40217
In article <EoXf8.1279$en5.9349@typhoon.sonic.net>, Speedy <speedracer67@yahoo.invalid> wrote: >Have you tried google image search? >Type in "xilinx virtex", click on the second image "[ More results from >www.chipworks.com ] ", and there is a Virtex II. Higher res would be nice, >maybe you already found this one. Thanks. The chipworks one wasn't very good, but I got some hits on xilinx's japanese press website. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 40218
Ken Mac wrote: > > Phil, > > Forgot to mention that the DAC is fed the 425kHz clock via a pin of my > Spartan-II. > > The DAC uses the negative edges of the 425kHz clock to take data from > process C. > > Process C uses the positive edges of the 425kHz clock to place data on the > serial data pin for the DAC and the negative edges then drive the DAC. > > My DAC output now seems to be irregular - what signal should I use to clock > my DAC now? I'm not quite sure what you mean by irregular. If you used a version of 425 kHz that had been synchronized to the 33 MHz clock, there would be noticable jitter in the timing of the DAC output. Do you mean jitter in the timing of new data output from the DAC? Hope this helps. -- Phil HaysArticle: 40219
> Note that the two Excalibur solutiuons are not exclusive of each other - you > can easily instantiate one or more Nios cores in the programmable portion of > the Excalibur ARM devices. OK. Whan i buy Nios devel kit, will there be support for ARMs also? There are two devel kits on Altera website (one for Nios and one for Arm), so suppose I don't get ARM support in Nios kit. Right? I must buy some module for Quartus in order to use Arms? A assume that development boards differ (one is pure fpga, and second if an fpga with Arm structure), but is software in both kits identical, or not? TIA jerryArticle: 40220
Jerry, look at this in a different way. NIOS provides you with a complete IP CPU solution. You can migrate this design between different Altera FPGAs, have more than 1 CPU on the FPGA and eventually even make an ASIC from the design. You are currently limited by speed (technology and implentation) to about 60MHz to 80MHz. The ARM option is a hardwired CPU on the FPGA running at 166MHz(?). If you suddenly need 2 or more ARM CPUs you will need more ICs. With NIOS you only upgrade to a bigger device and include another one. I would suggest that you go for the NIOS option first (only $995). With it you will everything you need. You will probably find that it might be cheaper to buy a standalone MIPS or ARM CPU than to have it included on a FPGA (please correct me if I am wrong). The other day a sales rep. from Avnet gave me a quote on ridiculous low prices on the new Hitachi 32bit CPUs. Even the compiler was something like only $400. I use NIOS because I can get my CPU, 4 serial ports, 67 I/O lines, timer, multiplier and WDT into one FPGA. My hardware stays the same while NIOS allows me to make tweeks to the hardware. Plus, the free compiler (you can redistribute it for free) makes it all the more better. Cost wise it might seem still a bit expensive. My entry level board (please email for more specs) currently sells for about $350 (small quantities). Victor "jerry1111" <jerry1111@wp.pl> wrote in message news:a5oj6f$mjh$1@news.tpi.pl... > Hello, > > I want to buy Altera's softcore uP. > Which one: Nios-based or Arm-based? > Any suggestions? > Before spending money for development tools I'd like > to know the good and bad news for it. > > Is it possible to move from Nios to Arm-based without > spending lot of money for Arm option (already having > Nios purchased)? > > Thanks > > jerry > >Article: 40221
> Jerry, look at this in a different way. NIOS provides you with a complete IP > CPU solution. You can migrate this design between different Altera FPGAs, > have more than 1 CPU on the FPGA and eventually even make an ASIC from the > design. You are currently limited by speed (technology and implentation) to > about 60MHz to 80MHz. Yeah, but sometimes I will need 1 FAST cpu (let's say hardwired ARM) and 2 or 3 slower Nioses on the same chip. I prefer writing 'parralel' code for 2 or 4 smaller uP rather than for one big uP. > You will probably find that it might be cheaper to buy a standalone MIPS or > ARM CPU than to have it included on a FPGA (please correct me if I am > wrong). The other day a sales rep. from Avnet gave me a quote on ridiculous > low prices on the new Hitachi 32bit CPUs. Even the compiler was something > like only $400. Are any GNU C compilers for ARM available? I didn't find them. jerryArticle: 40222
Ryan Henderson wrote: > Wow, I hope things really haven't gotten this bad.... Yes, they have! I applaud the original poster and his ambition. However, relocating for a tech position is generally a bad idea. You could be fired/laid-off while you are in the moving van with all of your stuff heading towards your new job and nobody would even tell you until you showed up for work. In fact, the person that hired you in the first place may have been canned by then. I'll bet you think I'm joking here. Hey, what is the new Silicon Valley status symbol? Employment. Tom > > > -RyanArticle: 40223
> I applaud the original poster and his ambition. However, relocating for > a tech position is generally a bad idea. You could be fired/laid-off > while you are in the moving van with all of your stuff heading towards This is true of any job. Part of making a sensible decision about whether the move is worth it involves studying the company, the division you'd be working in and other factors and determining if the position you're moving into will have a long-term existence. Relocating for a tech position is no more/less a bad idea than relocating for /any/ position. And luck is a big part of it. -- -- Lewin A.R.W. Edwards Replace spam with larwe when emailing! For-hire : http://www.zws.com/ Personal: http://www.larwe.com/ Day job: http://www.digi-frame.com/Article: 40224
I'm wondering if it is advisable to embed counting logic in an FSM, say for a delay. What I have been doing thus far is having an uber-module with the fsm logic in one sub-module and the delay in a down-counter sub-module. Then the FSM loads the counter with the delay count on a Meally output when transiting to the delay state, it then exits the delay state upon the counter reaching zero. I think it would make the design easier to follow if the counting were simply handled in the FSM with assignments and decrements. Is this a reasonable thing to do? How well do synthesis tools handle this? Can they still infer the counter? If I have multiple such delays in one FSM, will the tools recognize the delays are mutually exclusive and only synthesize a single shared counter? If any one has any insight it would be much appreciated. Joey
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