Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I can see where this approach can lead to a better powerup because the shift register will keep the DCM in reset until a few clock pulses arrive and pushes the reset signal off. However, I don't see how DCM will reset if clkin stops, or the DCM loses lock, since the LOCKED signal will fail and then that will hold the RESET and keep the DCM in permanent reset. The only thing that makes sense to me is to have the LOCKED fail signal start a counter, clocked by clkin, to generate a periodic short reset pulse that resets the DCM and hopefully clears the LOCKED failed condition. My only concern with this approach is that the clkin signal could fail on the exact count or clock cycle whereby the reset pulse was being generated, and this again would generate a situation where the DCM was bieing held in a permanent reset condition, hmmm, on second thought, I suppose that having the DCM in reset isn't so bad if clkin fails, it would just wait until clkin reappears, so I think I have my answer, thanks. > A simple inversion from LOCKED is perhaps a bit rough (I wouldn't do > that - and I helped design it!). But, to read the LOCKED status bit, and > the CLKIN_STOPPED status bit, OR them, and then set a bit to be clocked > out to reset the DCM (clocked from some other clock source) is a good > idea.Article: 76851
http://www.niktech.com/ReferenceGuide.pdf http://www.niktech.com/GettingStarted.pdf http://www.niktech.com/ReferenceGuide.pdfArticle: 76852
On Mon, 13 Dec 2004 11:37:47 -0800, Chris Ebeling wrote:
>> Artenz
>
> If you want a specific implementation, there are usually things about
> how you code a given function that can help the guide the tools to your
> intended solution.
> In this case, without the specific coding style the results are not
> optimal from an area (resource) standpoint. I will take this up the the
> synthesis folks.
Thanks. Restructuring the code like you suggest below may not always be a
viable option. For instance, if the logic is in one module, and the 4-1
mux in another (assuming this division makes sense from a design
standpoint), then you'd really want the tools to optimize this, rather
than rewrite the code in a way that makes it hard to maintain and
understand.
> Back to how do I get MUXF5/MUXF6.
> This implies eight to one multiplexing, so use a three bit select in the
> case statement.
>
> This following will produce the LUT4/MUXF5/MUXF6 logic:
>
> module lut_test8( a, b, c, f, s );
> input [3:0] a, b;
> input [1:0] s;
> input [1:0] f;
> output c;
>
> reg c;
>
> always @(a or b or f or s)
> case({s, f[1]})
> 4'b000: c = !f[0]? (a[0] & b[0]) : (a[0] | b[0]);
> 4'b010: c = !f[0]? (a[1] & b[1]) : (a[1] | b[1]);
> 4'b100: c = !f[0]? (a[2] & b[2]) : (a[2] | b[2]);
> 4'b110: c = !f[0]? (a[3] & b[3]) : (a[3] | b[3]);
>
> 4'b001: c = !f[0]? (a[0] ^ b[0]) : (a[0] & ~b[0]);
> 4'b011: c = !f[0]? (a[1] ^ b[1]) : (a[1] & ~b[1]);
> 4'b101: c = !f[0]? (a[2] ^ b[2]) : (a[2] & ~b[2]);
> 4'b111: c = !f[0]? (a[3] ^ b[3]) : (a[3] & ~b[3]);
> endcase
>
> endmodule
I may not always want to rewrite the code like this, but at least it's
good to know how it can be done, and perhaps apply this where it doesn't
hurt the readability too much and/or if performance is critical.
Thanks for your help.
Article: 76853Sean Durkin <smd@despammed.com> writes: > This makes vias in the signal path unavoidable, something I'd rather > not do if it can be avoided somehow. Any tips or tricks for this? Swap the differential pairs and to polarity inversion on the receiver. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 76854
Jim Brain wrote:
> I have tried reading up on CUPL for a CPLD project, but I have been less
> than successful. Is there a good tutorial on some of the advanced CUPL
> stuff?
>
> In my case, I have some combinatorial logic (CE_OUT=CE_IN & !A7 & !A6 &
> !A5 & !A4 & !A3), and I grok that pretty well.
>
> But, in my design, I need to implement a read/write register, and I
> can't find a good example in CUPL to implement it. The Data lines need
> to be HiZ unless the register is being accessed, and if it is, lines go
> to latch input if Write, lines go to latch output if read.
>
> Examples would be fine, or just links to a good tutorial that would show
> a register would be perfect.
These for Atmel devices - this for a HC574 Octal D type device :
[DB7..DB0].oe = !RDN;
/* Enable on READ LOW => read back Latch contents */
[DB7..DB0].ck = WRN; /* Latch on the trailing edge of WRN ___/=== */
[DB7..DB0].d = [DB7..DB0].io; /* D feeds from BUS io pins */
Also, some Atmel devices support this: - equiv to a HC573 Latch device
[DB7..DB0].LE = !WRN; /* Latch transparent during WRN LOW */
[DB7..DB0].L = [DB7..DB0].io; /* D feeds from BUS io pins */
-jg
Article: 76855
I'm using quartus 4.2, and create some fifo with the mega wizard.
on one side, synchronous data are writen at 27 MHz (from external
pins), and on the other side, I'm reading the data with a 80 MHz clock
(to my design).
The design assistant give me the following warnings :
Data bits are not synchronized when transferred between asynchronous
clock domains
Multiple data bits that are transferred across asynchronous clock
domains are synchronized, but not all bits may be aligned in receiving
clock domain
my fifos are :
- without common clock between read and write side
- the clocks are not synchronized
- in legacy synchronous mode
- perfomance are not maximized
What should I do ?
--
Ceci est une signature automatique de MesNews.
Site : http://www.mesnews.net
Article: 76856Stupid me! You were right! I cut the PCB traces of the VCCINT pins off the 3V3 rail and straped them to 1V5 - works perfectly! No heat, no config mess-up. Thanks for the advice. I guess it was obvious to the experinces guys out there. I slaped myself a few times after carefully looking over the datasheet. I guess now I have to clean up my reputation :). Thanks for helping! Alex.Article: 76857
I'm trying to determine the delay curve of a particular path in a Virtex2Pro -5 from min timing to max, including all points in between. Obviously I can get the two end points (min and max) from the timing analyzer, but I assume that points between the two don't necessarily fall on a straight line. I considered also plotting the max timing of the other speed grades (-7 and -6), but I don't know what their relationship to each other is, so I wouldn't know exactly where to plot them relative to the -5 max endpoint. If anyone knows where performance graphs might exist in the Xilinx documenation, or what the relationship of speed grades to each other is, I'd be most appreciative of a response. Thanks!Article: 76858
Alex Somesan wrote: (snip) > I cut the PCB traces of the VCCINT pins off the 3V3 rail and straped > them to 1V5 - works perfectly! No heat, no config mess-up. Thanks for > the advice. I guess it was obvious to the experinces guys out there. I > slaped myself a few times after carefully looking over the datasheet. I > guess now I have to clean up my reputation :). And now we all know how tough Cyclone is with excess VccINT. -- glenArticle: 76859
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote in news:cpnrgj$qv$1 @gnus01.u.washington.edu: > > > Alex Somesan wrote: > (snip) > >> I cut the PCB traces of the VCCINT pins off the 3V3 rail and straped >> them to 1V5 - works perfectly! No heat, no config mess-up. Thanks for >> the advice. I guess it was obvious to the experinces guys out there. I >> slaped myself a few times after carefully looking over the datasheet. I >> guess now I have to clean up my reputation :). > > And now we all know how tough Cyclone is with excess VccINT. > > -- glen > Alex, Don't let us "old timers" give you too much crap. We've all made this mistake in one form or another. It called experience. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.comArticle: 76860
Hi Jan, The construct written out in the vho netlist by Quartus was illegal, and that is the reason for the message. This bug exists in Quartus II 4.0, 4.1 and 4.2. In each of these versions, you can workaround this in one of two ways: The first described in the earlier post which is to use Assignments->EDA Settings->Simulation, turn Map Illegal Characters to on, OR the second which is Assignments->EDA Settings->SimulationMaintain Hierarchy to off. This bug will be fixed in Quartus II version 5.0. > >>I think that the _\ construction is illegal but to be honnest: I've no > >>desire to dig in the vhdl reference to see who is right, Cadence and > >>Synopsys versus Altera. > > > > > > Hope this helps, Subroto Datta Altera Corp.Article: 76861
Thanks to the responses. I'm gonna have a go at it on my own first and see what I come up with.Article: 76862
Craig, remember that "speed grades" are an artificial way of segregating devices that are naturally made with a continuum of performance parameters. To accomodate the unavoidable manufacturing spread, IC manufacturers sort the devices into bins, so that they can guarantee performance, but also sell the devices that came out slow or "not so fast". In a perfect world, all parameters would scale perfectly, i.e. a device marked slow would have all its delays longer by the same factor, as compared to the devices labeled fast. The world is not perfect. The only thing you can be sure of is that you will never buy a part that is slower than its specification. All parameters will be better than the spec, but not all by the same percentage. Let me therefore discourage you from your elaborate plans. There is no simple answer. Peter Alfke ============================== Craig Conway wrote: > I'm trying to determine the delay curve of a particular path in a > Virtex2Pro -5 from min timing to max, including all points in between. > Obviously I can get the two end points (min and max) from the timing > analyzer, but I assume that points between the two don't necessarily fall on > a straight line. I considered also plotting the max timing of the other > speed grades (-7 and -6), but I don't know what their relationship to each > other is, so I wouldn't know exactly where to plot them relative to the -5 > max endpoint. > > If anyone knows where performance graphs might exist in the Xilinx > documenation, or what the relationship of speed grades to each other is, I'd > be most appreciative of a response. > > Thanks!Article: 76863
Works great, heres the code: -- coregen dcm component dcm port( rst_in : in std_logic; clkin_in : in std_logic; locked_out : out std_logic; clkfx_out : out std_logic; clkfx180_out : out std_logic; clk0_out : out std_logic); end component; -- coregen 20 bit binary counter with threshold0 component bc20 port ( q : out std_logic_vector(19 downto 0); clk : in std_logic; q_thresh0 : out std_logic); end component; begin inst_dcm: dcm port map( rst_in => dcm_reset, clkin_in => oscin, locked_out => dcm_lock, clkfx_out => clk, clkfx180_out => sramclk, clk0_out => open ); dcm_reset_counter : bc20 port map ( q => open, clk => oscin, q_thresh0 => reset_cnt_pulse); dcm_reset <= reset_cnt_pulse and (not dcm_lock); -- Do a periodic reset pulse if no dcm lock is available -- The reset_cnt_pulse comes from a 20 bit counter threshold. -- It's a one 20ns pulse with a 20mS period @50MHz oscin frequency. -- This is twice the time needed for a 10mS LOCK. -- The counter clocks on oscin input, not the dcm output clk. -- scope <= reset_cnt_pulse; -- testing purposes -- should trigger but not be seen on scope -- because of tiny duty cycle reset_process:process (dcm_lock,resetpushbutton) begin reset <= not (dcm_lock and resetpushbutton); end process; Enjoy, Brad Smallridge b r a d @ a i v i s i o n . c o mArticle: 76864
It's amazing how everything can become a Xilinx vs Altera battle. It seems to me that the original posting was not really looking for the most compact solution. Both Altera and Xilinx can of course provide RAM-based shift registers, and as long as you stay below 16K length, the A and X solutions are indistinguishable. But let me fix one bad misstatement: It does of course take 45 SRL16s to implement a 720 bit shift register, but these 45 SRL16s fit in lessthan six CLBs, since there are eight LUTs in a CLB. That takes less silicon area than any big RAM in either Altera or Xilinx chips... Peter AlfkeArticle: 76865
"Alex Somesan" <alex.somesan@gmail.com> wrote in message news:1103050426.348763.286140@z14g2000cwz.googlegroups.com... > Stupid me! > You were right! > I cut the PCB traces of the VCCINT pins off the 3V3 rail and straped > them to 1V5 - works perfectly! No heat, no config mess-up. Thanks for > the advice. I guess it was obvious to the experinces guys out there. I > slaped myself a few times after carefully looking over the datasheet. I > guess now I have to clean up my reputation :). > Thanks for helping! > > Alex. > Good to hear it's working now. Luckily it's only a cheap easily replacable Cyclone and not a Stratix housed in a 1508 pin FBGA package that's worth several thousand $ :) JeroenArticle: 76866
There is a lot of square operations in my FPGA projects (using Xilinx VitexE). Now, I complete them by multiple, but this method is slice consuming and slow. As we know, square operation has many characters, which multiple operation of any random numberic don' have, then could we utilize these features to calculate square operations more economical and more fast? Thanks for all advice. Best RegardsArticle: 76867
GL, you have every right to expect your design to work. Any FIFO worth its name must accomodate two unrelated clock domains, one for reading, one for writing. That is actually quite trivial,using a dual-port RAM for the data storage. What is not so trivial is the reliable detection of FULL and EMPTY. I work at Altera's competitor, but I do assume that Cyclone can handle your requirements. Otherwise: Welcome to the end of the alphabet... I just tested our newest FIFO at roughly 500 and 200 MHz asynchronous reads and writes, going EMPTY 200 million times a second, for a whole week, with not a single decoding and control error. So it can be done... Peter Alfke, Xilinx Applications ======================== GL wrote: > I'm using quartus 4.2, and create some fifo with the mega wizard. > on one side, synchronous data are writen at 27 MHz (from external > pins), and on the other side, I'm reading the data with a 80 MHz clock > (to my design). > > The design assistant give me the following warnings : > > Data bits are not synchronized when transferred between asynchronous > clock domains > Multiple data bits that are transferred across asynchronous clock > domains are synchronized, but not all bits may be aligned in receiving > clock domain > > my fifos are : > - without common clock between read and write side > - the clocks are not synchronized > - in legacy synchronous mode > - perfomance are not maximized > > > What should I do ? > > -- > Ceci est une signature automatique de MesNews. > Site : http://www.mesnews.netArticle: 76868
In article <ee8aa81.-1@webx.sUN8CHnE>, fwj_733 <fwj@nmrs.ac.cn> wrote:
>There is a lot of square operations in my FPGA projects (using Xilinx
>VitexE).
There may be shortcuts if you need a series of squares, for example.
You can compute that as
sq = 0;
for (i = 1; i < n; ++i) {
sq = sq + (i << 1) - 1;
// i * i == sq
}
--
Ben Jackson
<ben@ben.com>
http://www.ben.com/
Article: 76869For Virtex II parts, I see that the Vih and Vil levels are the same for LVTTL and LVCMOS33, my question is are the input structures really different or are they the same for the two standards. Also, are the output structures for LVTTL the same as LVCMOS33, since both Vol are the same, and LVTTL Voh is a subset of LVCMOS33 Voh.Article: 76870
GL, Your design sounds OK to me, but it's hard to be sure without seeing it. Using FIFOs to transfer data between asynchronous clock domains is of course standard usage, so the Quartus megawizard FIFOs will work fine for that. I suspect we have an overzealous warning in the Design Assistant. The warning you're getting is that when you transfer a data word (that is wider than 1 bit), you have to be careful that all the bits arrive in the same cycle in the receiving clock domain. A FIFO will take care of that. If you send me your design, I'll open a software problem report on it, get someone to check that the design analyzer isn't being too overcautious, and if it is we'll fix this case. Regards, Vaughn Betz Altera v b e t z (at) altera.com [Remove spaces and add @ to reach me] "GL" <a@b.c> wrote in message news:mn.753a7d4ca170b3de.23732@b.c... > I'm using quartus 4.2, and create some fifo with the mega wizard. > on one side, synchronous data are writen at 27 MHz (from external > pins), and on the other side, I'm reading the data with a 80 MHz clock > (to my design). > > The design assistant give me the following warnings : > > Data bits are not synchronized when transferred between asynchronous > clock domains > Multiple data bits that are transferred across asynchronous clock > domains are synchronized, but not all bits may be aligned in receiving > clock domain > > my fifos are : > - without common clock between read and write side > - the clocks are not synchronized > - in legacy synchronous mode > - perfomance are not maximized > > > What should I do ? > > -- > Ceci est une signature automatique de MesNews. > Site : http://www.mesnews.net >Article: 76871
> It's amazing how everything can become a Xilinx vs Altera battle. > It seems to me that the original posting was not really looking for the > most compact solution. Peter, If you check my post, you will see that I was replying to the poster's question of whether or not Altera was at a disadvantage on shift registers vs. Xilinx. > Both Altera and Xilinx can of course provide > RAM-based shift registers, and as long as you stay below 16K length, > the A and X solutions are indistinguishable. The area of a Xilinx BlockRAM (18 kbit RAM) is of course a lot larger than that of either an Altera M512 RAM (576 bits) or an Altera M4K RAM (4.5 kbit). All the extra RAM area beyond what the shift register needs is wasted, so having a variety of RAM sizes and a lot of smaller RAMs makes for a more efficient FIFO mapping of shift registers than having only a relatively small nuber of BlockRAMs of one size. Now, of course Xilinx has the SRL16's to implement smaller shift registers, so it's less crucial to have small RAMs around to build FIFOs for moderate size shift registers. The solutions are different, and you can argue about which is better, but they are certainly not indistinguisable. > But let me fix one bad misstatement: > It does of course take 45 SRL16s to implement a 720 bit shift > register, but these 45 SRL16s fit in lessthan six CLBs, since there are > eight LUTs in a CLB. > That takes less silicon area than any big RAM in either Altera or > Xilinx chips... An M4K RAM also takes less area than 6 CLBs, and can do a significantly bigger shift register than 720 bits. An M512 can't quite do 720 bits, (can do 512 bit shifts) and has an area that's somewhere in the 1 to 2 CLB range. So I don't agree with your argument that area is lower for SRL16's for this case. Vaughn Betz Altera v b e t z (at) altera.com [Remove spaces and put in proper @ to reach me] "Peter" <peter@xilinx.com> wrote in message news:1103074788.884558.87760@f14g2000cwb.googlegroups.com... > It's amazing how everything can become a Xilinx vs Altera battle. > It seems to me that the original posting was not really looking for the > most compact solution. Both Altera and Xilinx can of course provide > RAM-based shift registers, and as long as you stay below 16K length, > the A and X solutions are indistinguishable. > > But let me fix one bad misstatement: > It does of course take 45 SRL16s to implement a 720 bit shift > register, but these 45 SRL16s fit in lessthan six CLBs, since there are > eight LUTs in a CLB. > That takes less silicon area than any big RAM in either Altera or > Xilinx chips... > > Peter Alfke >Article: 76872
Hello,
I have the following code :
width = 128
architecture bhv of yy is
function Stop_Sense ( IsSigCell, StopNextCells : std_ulogic_vector(Width-1
downto 0);
CurrentCell : natural range 0 to Width-1;
LookAheadDepth : natural range 1 to 16
) return std_ulogic is
begin
L1:for i in 1 to LookAheadDepth - 1 loop
if (CurrentCell - i) >= 0 then
if StopNextCells(CurrentCell - i) = '1' then
return '1';
else
if IsSigCell(CurrentCell - i) = '1' then
exit;
end if;
end if;
end if;
end loop;
return '0';
end;
signal StopNextCells : std_ulogic_vector (Width-1 downto 0);
signal StopCell : std_ulogic_vector (Width-1 downto 0);
signal IsBoundaryCell : std_ulogic_vector (Width-1 downto 0);
begin
.
.
StopCells: for i in 0 to Width-1 generate
StopCell(i) <= Stop_Sense(IsBoundaryCell, StopNextCells, i, N1_max);
end generate;
.
.
end bhv;
The function returns '1' when the StopNextCells vector contains at least a
'1' after the CurrentCell position and before the CurrentCell+LookAheadDepth
position and the first '1' in the IsSigCell vector.
Works OK in simulation, but quartus synthesize this as a simple OR on the
next N1_max StopNextCells positions which is not the intended behaviour.
What am I doing wrong in the code ?
BTW, I have 2 of these entities, plus as much of 2 other kinds of this, so I
have the equivalent of 1024 of these functions. Is there a more efficient
way to pack the logic ?
--
Thanks,
Fred.
Article: 76873Symon wrote: > Sean, > Rotate one of the FPGAs by 180 degrees. Won't help, the TX/RX positions are exactly the same on top and bottom side. If I rotate one FPGA, I again have TX-pairs opposite of other TX-pairs, so to get to the RX-pair I have to cross signals again, same thing... cu, SeanArticle: 76874
Sean Durkin wrote: > Symon wrote: > >> Sean, >> Rotate one of the FPGAs by 180 degrees. > > Won't help, the TX/RX positions are exactly the same on top and bottom > side. If I rotate one FPGA, I again have TX-pairs opposite of other > TX-pairs, so to get to the RX-pair I have to cross signals again, same > thing... I take back everything I said and confess my stupidity to this newsgroup... have you ever had one of those days...? :) Of course Symon was right... cu, Sean
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