Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 104900

Article: 104900
Subject: PPC XMK bootloader for ELF files
From: s1r.h3nry@gmail.com
Date: 8 Jul 2006 17:40:36 -0700
Links: << >>  << T >>  << A >>
I'm trying to get a Virtex4 PPC405 boot loader to run an ELF file
stored in DRAM.

I have setup the PPC to read binaries from an RS232 and store them in
the DRAM.  I've also setup my PC to transfer an ELF file to the PPC.
Now I want to execute the ELF from DRAM, but it isn't working.  Using
checksums, I've verified that the file is transferred correctly.

My DRAM starts at 0x00000000, I'm using the XMK function
elf_process_create(0, 0) to try to launch the process.  My linker
script for the ELF code I'm trying to launch is attached below.  This
was generated by the Xilinx EDK, with the entry point changed to _start
from _boot.  Is there anything obvious I'm doing wrong?  I'm pretty new
to this stuff, and any advice would be appreciated.

Thanks in advance,
-Till Rosenband

/* Linker script: */
_STACK_SIZE = DEFINED(_STACK_SIZE) ? _STACK_SIZE : 0x1000;
_HEAP_SIZE = DEFINED(_HEAP_SIZE) ? _HEAP_SIZE : 0x1000;

/* Define Memories in the system */

MEMORY
{
   DDR_SDRAM_32Mx16_C_MEM0_BASEADDR : ORIGIN = 0x00000000, LENGTH =
0x03FFFFFF
}

/* Specify the default entry point to the program */

/* ENTRY(_boot)
STARTUP(boot.o) */

ENTRY(_start)

/* Define the sections, and where they are mapped in memory */

SECTIONS
{
.text : {
   *(.text)
   *(.text.*)
   *(.gnu.linkonce.t.*)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.init : {
   KEEP (*(.init))
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.fini : {
   KEEP (*(.fini))
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.rodata : {
   __rodata_start = .;
   *(.rodata)
   *(.rodata.*)
   *(.gnu.linkonce.r.*)
   __rodata_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.sdata2 : {
   __sdata2_start = .;
   *(.sdata2)
   *(.gnu.linkonce.s2.*)
   __sdata2_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.sbss2 : {
   __sbss2_start = .;
   *(.sbss2)
   *(.gnu.linkonce.sb2.*)
   __sbss2_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.data : {
   __data_start = .;
   *(.data)
   *(.data.*)
   *(.gnu.linkonce.d.*)
   __data_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.got : {
   *(.got)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.got1 : {
   *(.got1)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.got2 : {
   *(.got2)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.ctors : {
   __CTOR_LIST__ = .;
   ___CTORS_LIST___ = .;
   KEEP (*crtbegin.o(.ctors))
   KEEP (*(EXCLUDE_FILE(*crtend.o) .ctors))
   KEEP (*(SORT(.ctors.*)))
   KEEP (*(.ctors))
   __CTOR_END__ = .;
   ___CTORS_END___ = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.dtors : {
   __DTOR_LIST__ = .;
   ___DTORS_LIST___ = .;
   KEEP (*crtbegin.o(.dtors))
   KEEP (*(EXCLUDE_FILE(*crtend.o) .dtors))
   KEEP (*(SORT(.dtors.*)))
   KEEP (*(.dtors))
   __DTOR_END__ = .;
   ___DTORS_END___ = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.fixup : {
   __fixup_start = .;
   *(.fixup)
   __fixup_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.eh_frame : {
   *(.eh_frame)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.jcr : {
   *(.jcr)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.gcc_except_table : {
   *(.gcc_except_table)
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.sdata : {
   __sdata_start = .;
   *(.sdata)
   *(.gnu.linkonce.s.*)
   __sdata_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.sbss : {
   __sbss_start = .;
   *(.sbss)
   *(.gnu.linkonce.sb.*)
   __sbss_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.tdata : {
   __tdata_start = .;
   *(.tdata)
   *(.gnu.linkonce.td.*)
   __tdata_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.tbss : {
   __tbss_start = .;
   *(.tbss)
   *(.gnu.linkonce.tb.*)
   __tbss_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

.bss : {
   __bss_start = .;
   *(.bss)
   *(.gnu.linkonce.b.*)
   *(COMMON)
   . = ALIGN(4);
   __bss_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

/* Generate Stack and Heap Sections */

bss_stack : {
   . += _STACK_SIZE;
   . = ALIGN(16);
   __stack = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

bss_heap : {
   . = ALIGN(16);
   _heap_start = .;
   . += _HEAP_SIZE;
   . = ALIGN(16);
   _heap_end = .;
} > DDR_SDRAM_32Mx16_C_MEM0_BASEADDR

}


Article: 104901
Subject: Mystery CLKDLL, IBUFG, BUFG modules in verilog src (ISE 6.3.03i)
From: beagle197@hotmail.com
Date: 8 Jul 2006 18:59:49 -0700
Links: << >>  << T >>  << A >>
Folks,

[Beginner] I've been trying to decypher a reference design that
contains verilog source and instantiation of modules CLKDLL, IBUFG, and
BUFG. Reading through the source, seven_seg.v, I find the instantiation
of objects CLKDLL, IBUFG, and BUFG, but no source verilog for them. It
was provided with development board Xilinx Spartan-3 LC Kit from
Avnet*. I am using ISE 6.3.03i from Xilinx to load the design onto the
board. The problem I am having is that there is no source provided for
these modules, so I am not sure if the ISE fills in their definition
given that project targets the xc3s400-4pq208, or if the user
constraint file (UCF) provides the necessary details, given that the
FPGA chip itself provides the hardware (digital clock manager, i.e.
DCM) that implements the reference.** Since the reference design works,
how are these modules being resolved by the synthesizer (xst) or in the
design flow (e.g. mapper, etc)? If they are coming from a library, how
can I find the documentation explaining these modules? What other
verilog modules are available for us in designs (e.g. where is this
documented)? I know, for example, that this chip has a multiplier.

Thanks for reading,
BEA

*[http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D25448%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html]
**[http://www.xilinx.com/bvdocs/appnotes/xapp462.pdf]

//***********************************************************************************
//*        File Name:   seven_seg.v
//*          Version:   1.0
//*             Date:   February 10, 2004
//*   File Hierarchy:   Low level module
//*     Dependencies:   None
//*
//*         Designer:
//*          Company:   Memec
//*
//*
//*      Description:   This module does the following:
//*                      1. Creates a 1-second enable signal with a
logic counter
//*                      2. Based on PUSH[2]:
//*                          Held down :  Counts 0-9 on 7-segment
display
//*                          Released  :  Displays 4-bit binary DIP
switch value in hex
//*                      3. PUSH[1] serves as the system reset
//*                      4. LEDs count 0-9
//*
//************************************************************************************


module seven_seg (CLK, PUSH, DIP, DISPLAY, LED);

// Input Declarations
input           CLK;          //surface-mount 50MHz oscillator
input    [2:1]  PUSH;         //push-button switches
input    [3:0]  DIP;          //DIP[3] is SW3[1] on the board

// Output Declarations
output   [6:0]  DISPLAY;      //7-segment display DD1
output   [4:1]  LED;          //user LEDs

// Input Registers
reg      [3:0]  DIP_r [3:0]; // 4x4 array to hold registered versions
of DIP
reg      [3:0]  DIP_d;       // debounced DIP
reg      [3:0]  PUSH1_r;     // registered version of PUSH1
reg      [3:0]  PUSH2_r;     // registered version of PUSH2
reg             PUSH1_d;     // debounced PUSH1
reg             PUSH2_d;     // debounced PUSH2

// Output Registers
reg      [4:1]  LED;
reg      [6:0]  DISPLAY;

// Other Registers
reg      [22:0] led_count;
reg      [3:0]  led_seg_count;
reg             reset;   // high-asserted reset

// Internal signals
wire            led_count_en;
wire            clk_i, clk_fb, clk0, clkdv, clk_div16;
integer         i;

/* Using CLKDLL to divide the input 50 MHz clock by 16
   resulting in a 3.125 MHz internal clock */
IBUFG     U1 ( .I(CLK), .O(clk_i));

CLKDLL    dll_div_by_16 ( .CLKIN(clk_i), .CLKFB(clk_fb), .RST(1'b0),
               .CLK0(clk0), .CLK90(), .CLK180(), .CLK270(),
               .CLK2X(), .CLKDV(clkdv), .LOCKED());

BUFG      U3 ( .I(clk0), .O(clk_fb));
BUFG      U4 ( .I(clkdv), .O(clk_div16));

// Register and debounce push buttons and switches
// If the bouncy signal is high, 4 consecutive lows required to pull it
low
// If the bouncy signal is low, 4 consecutive highs required to pull it
high
always @(posedge clk_div16)
   begin
     PUSH1_r[0] <= PUSH[1];
     PUSH1_r[1] <= PUSH1_r[0];
     PUSH1_r[2] <= PUSH1_r[1];
     PUSH1_r[3] <= PUSH1_r[2];
     if(PUSH1_d)
          PUSH1_d <= |PUSH1_r;
     else
          PUSH1_d <= &PUSH1_r;
     reset      <= ~PUSH1_d;

     PUSH2_r[0] <= PUSH[2];
     PUSH2_r[1] <= PUSH2_r[0];
     PUSH2_r[2] <= PUSH2_r[1];
     PUSH2_r[3] <= PUSH2_r[2];
     if(PUSH2_d)
          PUSH2_d <= |PUSH2_r;
     else
          PUSH2_d <= &PUSH2_r;

     // Register the 4-bit DIP switch 4 times
     DIP_r[0]      <= DIP;
     DIP_r[1]      <= DIP_r[0];
     DIP_r[2]      <= DIP_r[1];
     DIP_r[3]      <= DIP_r[2];

     // Debounce the DIPs based on the register contents
     // For each bit, 0 through 3, switch polarity only when 4 opposite
     //     polarity is seen for four consecutive clocks.
     for (i = 0; i < 4; i = i+1)
       begin
          if(DIP_d[i])
               DIP_d[i] <= DIP_r[0][i] | DIP_r[1][i] | DIP_r[2][i] |
DIP_r[3][i];
          else
               DIP_d[i] <= DIP_r[0][i] & DIP_r[1][i] & DIP_r[2][i] &
DIP_r[3][i];
       end

   end


//    Segment diagram for the 7-segment LED display (low-enabled).
//
//          0
//       -------
//      5|     |1
//       |     |
//       ---6---
//      4|     |2
//       |     |
//       -------
//          3


// Register outputs
always @(posedge clk_div16)
   begin
     if(reset)                 //synchronous reset
       begin
          DISPLAY <= 7'h7f;    //turn off displays during reset
          LED     <= 4'hf;     //turn off LEDs during reset
       end
     else
       begin
          //   LEDs count binary 0-9 based on led_seg_count
          LED <= ~led_seg_count;
          //   If PUSH2 is pushed (connecting it with GND), encode a
          //   binary number (0-9) from the counter and displays it
          //   on the 7-segment LED Display.
          //   Otherwise, read the DIP switch and output the hex
          //   value on the 7-segment LED Display
          if (!PUSH2_d)
            begin
              case (led_seg_count)
                      0:   DISPLAY   <= ~(7'b0111111);
                      1:   DISPLAY   <= ~(7'b0000110);
                      2:   DISPLAY   <= ~(7'b1011011);
                      3:   DISPLAY   <= ~(7'b1001111);
                      4:   DISPLAY   <= ~(7'b1100110);
                      5:   DISPLAY   <= ~(7'b1101101);
                      6:   DISPLAY   <= ~(7'b1111101);
                      7:   DISPLAY   <= ~(7'b0000111);
                      8:   DISPLAY   <= ~(7'b1111111);
                      9:   DISPLAY   <= ~(7'b1101111);
                default:   DISPLAY   <= 7'b1111111;
              endcase
            end
          else
            begin
              case (~DIP_d)
                      0:   DISPLAY   <= ~(7'b0111111);
                      1:   DISPLAY   <= ~(7'b0000110);
                      2:   DISPLAY   <= ~(7'b1011011);
                      3:   DISPLAY   <= ~(7'b1001111);
                      4:   DISPLAY   <= ~(7'b1100110);
                      5:   DISPLAY   <= ~(7'b1101101);
                      6:   DISPLAY   <= ~(7'b1111101);
                      7:   DISPLAY   <= ~(7'b0000111);
                      8:   DISPLAY   <= ~(7'b1111111);
                      9:   DISPLAY   <= ~(7'b1101111);
                   4'hA:   DISPLAY   <= ~(7'b1110111);
                   4'hb:   DISPLAY   <= ~(7'b1111100);
                   4'hC:   DISPLAY   <= ~(7'b0111001);
                   4'hd:   DISPLAY   <= ~(7'b1011110);
                   4'hE:   DISPLAY   <= ~(7'b1111001);
                   4'hF:   DISPLAY   <= ~(7'b1110001);
                default:   DISPLAY   <= 7'b1111111;
              endcase
            end  // end else (!PUSH2_d)
       end  // end else (reset)
   end  // end always block



//   The following block generates numbers 0-9 to be displayed on the
7-segment
//   display. This 4-bit counter is loaded with the binary value of the
on-board
//   DIP switch on reset. Once the reset goes inactive, the count will
begin. The
//   counter will hold its last count when the count_hold_n signal goes
active. This
//   4-bit counter will only count 0-9 and is reset to zero when the
counter reaches
//   decimal 9.
always @(posedge clk_div16)
   begin
      if (reset)
            led_seg_count <= 4'hf;
      else if ((led_seg_count == 4'h9) & (led_count_en == 1'b1))
            led_seg_count <= 0;
      else if (led_count_en == 1'b1)
            led_seg_count <= led_seg_count + 1;
   end


//   The following counter is used as a prescaler to the above 4-bit
counter.
//   The input clock is divided to enable the 4-bit counter once per
second.
always @(posedge clk_div16)
   begin
      if (reset)
         led_count <= 0;
      else
         if (led_count_en)
          led_count <= 0;
         else
          led_count <= led_count + 1;
   end

assign   led_count_en   = (led_count == 22'd3_125_000);   // Create
1-second count

endmodule

#***********************************************************************************
#*          Project:   Memec Board Spartan-3 400 LC
#*
#*        File Name:   seven_seg.ucf
#*          Version:   1.0
#*             Date:   February 10, 2004
#*
#*         Designer:
#*          Company:   Memec
#*
#*
#*      Description:   This module tests the 7-Segment LED display,
DIPs, and
#*                     push buttons
#*
#************************************************************************************

# Force the FPGA to assert DONE after the DLL locks
INST     "dll_div_by_16" STARTUP_WAIT=TRUE;

# Specify a 50 MHz constraint with a Divide-by-16 in the DLL
NET      "CLK" TNM_NET = "CLK";
TIMESPEC "TS_CLK" = PERIOD "CLK" 50 MHz HIGH 50 %;
INST     "dll_div_by_16" CLKDV_DIVIDE = 16;


# I/O Placement and timing constraints

# Specify set-up and clk-out times
OFFSET = IN  2.4 ns BEFORE "CLK";
OFFSET = OUT 1.9 ns AFTER  "CLK";

# Locate DCM & BUFG to ensure they are on the same side as the clk pin
INST "dll_div_by_16" LOC = "DCM_X0Y1"  ;
INST "U3"            LOC = "BUFGMUX7"  ;
INST "U4"            LOC = "BUFGMUX6"  ;


# I/O input constraints
NET "CLK"   LOC = "P184" | IOSTANDARD = LVCMOS33; # SMT clock, JP30
must have jumper at 1-2
# NET "CLK"   LOC = "P183"; # clock socket

NET "PUSH<1>"      LOC = "P22";
NET "PUSH<2>"      LOC = "P24";
NET "PUSH<*>"      PULLUP | IOSTANDARD = LVCMOS33;

NET "DIP<3>"       LOC = "P26";
NET "DIP<2>"       LOC = "P27";
NET "DIP<1>"       LOC = "P28";
NET "DIP<0>"       LOC = "P29";
NET "DIP<*>"       PULLUP | IOSTANDARD = LVCMOS33;

# I/O Output Constraints
NET "DISPLAY<0>"   LOC = "P36"; # DISPLAY.1A
NET "DISPLAY<1>"   LOC = "P37"; # DISPLAY.1B
NET "DISPLAY<2>"   LOC = "P39"; # DISPLAY.1C
NET "DISPLAY<3>"   LOC = "P33"; # DISPLAY.1D
NET "DISPLAY<4>"   LOC = "P31"; # DISPLAY.1E
NET "DISPLAY<5>"   LOC = "P34"; # DISPLAY.1F
NET "DISPLAY<6>"   LOC = "P35"; # DISPLAY.1G

NET "DISPLAY<*>"   FAST | DRIVE = 24 | IOSTANDARD = LVCMOS33;

NET "LED<1>"       LOC = "P19";
NET "LED<2>"       LOC = "P18";
NET "LED<3>"       LOC = "P21";
NET "LED<4>"       LOC = "P20";
NET "LED<*>"       FAST | DRIVE = 24 | IOSTANDARD = LVCMOS33;


Article: 104902
Subject: Re: Mystery CLKDLL, IBUFG, BUFG modules in verilog src (ISE 6.3.03i)
From: John_H <johnhandwork@mail.com>
Date: Sun, 09 Jul 2006 02:28:11 GMT
Links: << >>  << T >>  << A >>
beagle197@hotmail.com wrote:
> Folks,
> 
> [Beginner] I've been trying to decypher a reference design that
> contains verilog source and instantiation of modules CLKDLL, IBUFG, and
> BUFG. Reading through the source, seven_seg.v, I find the instantiation
> of objects CLKDLL, IBUFG, and BUFG, but no source verilog for them. It
> was provided with development board Xilinx Spartan-3 LC Kit from
> Avnet*. I am using ISE 6.3.03i from Xilinx to load the design onto the
> board. The problem I am having is that there is no source provided for
> these modules, so I am not sure if the ISE fills in their definition
> given that project targets the xc3s400-4pq208, or if the user
> constraint file (UCF) provides the necessary details, given that the
> FPGA chip itself provides the hardware (digital clock manager, i.e.
> DCM) that implements the reference.** Since the reference design works,
> how are these modules being resolved by the synthesizer (xst) or in the
> design flow (e.g. mapper, etc)? If they are coming from a library, how
> can I find the documentation explaining these modules? What other
> verilog modules are available for us in designs (e.g. where is this
> documented)? I know, for example, that this chip has a multiplier.
> 
> Thanks for reading,
> BEA
> 
> *[http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D25448%2526CCD%253DUSA%2526SID%253D4742%2526DID%253DDF2%2526SRT%253D1%2526LID%253D18806%2526PVW%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html]
> **[http://www.xilinx.com/bvdocs/appnotes/xapp462.pdf]
<code snipped>

The modules instantiated in the code are Xilinx primitives that 
correspond to low-level silicon functions not described (for the 
purposes of synthesis) by Verilog code.

Please see the Xilinx Library Guide available in the Xilinx.com online 
software manuals to see descriptions of those modules.

Article: 104903
Subject: Re: Mystery CLKDLL, IBUFG, BUFG modules in verilog src (ISE 6.3.03i)
From: beagle197@hotmail.com
Date: 8 Jul 2006 20:31:44 -0700
Links: << >>  << T >>  << A >>
Super, I found it there, thanks (!) BEA

John_H wrote:
> beagle197@hotmail.com wrote:
> > ... I've been trying to decypher a reference design that
> > contains verilog source and instantiation of modules CLKDLL, IBUFG, and
> > BUFG. Reading through the source, seven_seg.v, I find the instantiation
> > of objects CLKDLL, IBUFG, and BUFG, but no source verilog for them. ...
> > If they are coming from a library, how
> > can I find the documentation explaining these modules?
>
> The modules instantiated in the code are Xilinx primitives that
> correspond to low-level silicon functions not described (for the
> purposes of synthesis) by Verilog code.
>
> Please see the Xilinx Library Guide available in the Xilinx.com online
> software manuals to see descriptions of those modules.


Article: 104904
Subject: SP305- PROM configuration
From: "Jan Hansen" <someone@microsoft.com>
Date: Sun, 9 Jul 2006 08:30:31 +0200
Links: << >>  << T >>  << A >>
I have a valid bitstream and it works fine in the FPGA.

BUT !

How do I convert this bitstream into a PROM-file and get the SP305 to work
with it ?



Article: 104905
Subject: Re: Can I use all 18bits of a BlockRAM?
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 09 Jul 2006 01:43:56 -0500
Links: << >>  << T >>  << A >>
In article <1152393183.529370.98410@75g2000cwc.googlegroups.com>,
 "Peter Alfke" <alfke@sbcglobal.net> writes:
>I wish we had never called them "parity bits". They are just extra bits
>(above the traditional power of two) that can be used for anything.
>Parity is just one of the popular applications, nothing more..

For network applications, they are fantastic as end-of-packet markers.

-- 
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: 104906
Subject: Re: SP305- PROM configuration
From: "Antti" <Antti.Lukats@xilant.com>
Date: 9 Jul 2006 00:30:39 -0700
Links: << >>  << T >>  << A >>
Jan Hansen schrieb:

> I have a valid bitstream and it works fine in the FPGA.
>
> BUT !
>
> How do I convert this bitstream into a PROM-file and get the SP305 to work
> with it ?

by using Xilinx Impact tool.
you may need to read some board docu to setup the jumpers and options
properly.

Antti
http://antti-brain.com


Article: 104907
Subject: Weird JTAG lockup issue, where is the BUG?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 9 Jul 2006 00:50:43 -0700
Links: << >>  << T >>  << A >>
Hi

I have several Spartan3 boards that have a very weird issue, namly when
configured with one specific VHDL design using Impact with verify off
then after first programming attempt (status fail with CRC check!) the
JTAG chain is reported broken before the FPGA and further configuration
or even jtag idcode reading is not possible until complete power off
the FPGA. When imact option verify is on then however the same
bitstream can be used to configure the boards multiply times, the JTAG
lockup doesnt happen. It is not related to bad bitstream because the
VHDL design (LEON3 system) when compiled to different FPGA (S3-1500 or
s3-4000) has the same behaviour. The boards in question (2 different
PCBs) seem to work with all other design I have tested.

To my understanding the JTAG TAP controller should be completly
separate function block from the FPGA fabric - so no matter what is
loaded as FPGA config should not make the JTAG TAP unscannable. So the
issue could be only related to power supply behaviour, some voltage
spike at FPGA startup?

Any ideas what to test or where to look? Or what to test. I would
really like to get to the bottom of the problem and understand how come
does LEON3 design make the JTAG Chain to die (this is what is looks
like for the moment).

The FPGAs on the boards where I see this behaviour are with date codes
mentioned in

http://direct.xilinx.com/bvdocs/notifications/xcn06018.pdf

but I dont think this could be the issue?

Antti


Article: 104908
Subject: Re: Mystery CLKDLL, IBUFG, BUFG modules in verilog src (ISE 6.3.03i)
From: "johnp" <johnp3+nospam@probo.com>
Date: 9 Jul 2006 08:19:39 -0700
Links: << >>  << T >>  << A >>
Xilinx does provide source for their primitives for simulation
purposes.
Take a look in your Xilinx install directory in the verilog/src/unisims
subdirectory.


John Providenza


Article: 104909
Subject: Re: Weird JTAG lockup issue, where is the BUG?
From: nico@puntnl.niks (Nico Coesel)
Date: Sun, 09 Jul 2006 15:36:06 GMT
Links: << >>  << T >>  << A >>
"Antti" <Antti.Lukats@xilant.com> wrote:

>Hi
>
>I have several Spartan3 boards that have a very weird issue, namly when
>configured with one specific VHDL design using Impact with verify off
>then after first programming attempt (status fail with CRC check!) the
>JTAG chain is reported broken before the FPGA and further configuration
>or even jtag idcode reading is not possible until complete power off
>the FPGA. When imact option verify is on then however the same
>bitstream can be used to configure the boards multiply times, the JTAG
>lockup doesnt happen. It is not related to bad bitstream because the
>VHDL design (LEON3 system) when compiled to different FPGA (S3-1500 or
>s3-4000) has the same behaviour. The boards in question (2 different
>PCBs) seem to work with all other design I have tested.
>
>To my understanding the JTAG TAP controller should be completly
>separate function block from the FPGA fabric - so no matter what is
>loaded as FPGA config should not make the JTAG TAP unscannable. So the
>issue could be only related to power supply behaviour, some voltage
>spike at FPGA startup?

I've had this problem with Spartan2 fpga's. I even cooked a few! So
far I could trace the problem, it had to do with power supply current
capability and bypassing. Sometimes the fpga will draw a huge amount
of current during configuration. If the power supply system (including
the bypass capacitors) can't supply this current, you'll have some
latch-ups in the fpga.

-- 
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Article: 104910
Subject: Re: Weird JTAG lockup issue, where is the BUG?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 9 Jul 2006 09:30:08 -0700
Links: << >>  << T >>  << A >>
Nico Coesel schrieb:

> "Antti" <Antti.Lukats@xilant.com> wrote:
>
> >Hi
> >
> >I have several Spartan3 boards that have a very weird issue, namly when
> >configured with one specific VHDL design using Impact with verify off
> >then after first programming attempt (status fail with CRC check!) the
> >JTAG chain is reported broken before the FPGA and further configuration
> >or even jtag idcode reading is not possible until complete power off
> >the FPGA. When imact option verify is on then however the same
> >bitstream can be used to configure the boards multiply times, the JTAG
> >lockup doesnt happen. It is not related to bad bitstream because the
> >VHDL design (LEON3 system) when compiled to different FPGA (S3-1500 or
> >s3-4000) has the same behaviour. The boards in question (2 different
> >PCBs) seem to work with all other design I have tested.
> >
> >To my understanding the JTAG TAP controller should be completly
> >separate function block from the FPGA fabric - so no matter what is
> >loaded as FPGA config should not make the JTAG TAP unscannable. So the
> >issue could be only related to power supply behaviour, some voltage
> >spike at FPGA startup?
>
> I've had this problem with Spartan2 fpga's. I even cooked a few! So
> far I could trace the problem, it had to do with power supply current
> capability and bypassing. Sometimes the fpga will draw a huge amount
> of current during configuration. If the power supply system (including
> the bypass capacitors) can't supply this current, you'll have some
> latch-ups in the fpga.
>
> --
> Reply to nico@nctdevpuntnl (punt=.)
> Bedrijven en winkels vindt U op www.adresboekje.nl

hi thanks for answer,

and yes that is what I think also the problem could be.

but I assumed the Spartan 3 has no special requirements of huge
currents required to startup.

both 1.2 and 2.5V powersupplies are 6A step-downs from LT and look like
really designed by the book. Gosh I really hate if I need to
troubleshoot them.

I still wonder why the latchup never happens when I select "verify on"
in impact !?

guess I need to setup up DSO trigger on done=1 and monitor all the
supplies at the transition time.

Antti


Article: 104911
Subject: Re: Weird JTAG lockup issue, where is the BUG?
From: "Rob" <robnstef@frontiernet.net>
Date: Sun, 09 Jul 2006 18:24:40 GMT
Links: << >>  << T >>  << A >>
I'm not that familiar with Xilinx's FPGA's; but I did have an issue with an 
Altera FPGA that turned out to be power supply related.  The problem was 
that the power-up configuration was unstable, sometimes it would work and 
other times it wouldn't.  But, if I powered up, then initiated a 
configuration (from an on board push-button), it always worked.  This led me 
to look at the power rails. In my case, I had a power supply that was 
generating a non-monotonic rise on VCCint.  Once I fixed the rise so that it 
was smooth the problem went away.

Can you initiate, or re-initiate, the configuration cycle after you are 
powerd up and the voltage rails are stable?  If so, try it, and see what 
happens.  It may give you another clue.

Take care,
Rob



"Antti" <Antti.Lukats@xilant.com> wrote in message 
news:1152431443.921543.193450@m79g2000cwm.googlegroups.com...
> Hi
>
> I have several Spartan3 boards that have a very weird issue, namly when
> configured with one specific VHDL design using Impact with verify off
> then after first programming attempt (status fail with CRC check!) the
> JTAG chain is reported broken before the FPGA and further configuration
> or even jtag idcode reading is not possible until complete power off
> the FPGA. When imact option verify is on then however the same
> bitstream can be used to configure the boards multiply times, the JTAG
> lockup doesnt happen. It is not related to bad bitstream because the
> VHDL design (LEON3 system) when compiled to different FPGA (S3-1500 or
> s3-4000) has the same behaviour. The boards in question (2 different
> PCBs) seem to work with all other design I have tested.
>
> To my understanding the JTAG TAP controller should be completly
> separate function block from the FPGA fabric - so no matter what is
> loaded as FPGA config should not make the JTAG TAP unscannable. So the
> issue could be only related to power supply behaviour, some voltage
> spike at FPGA startup?
>
> Any ideas what to test or where to look? Or what to test. I would
> really like to get to the bottom of the problem and understand how come
> does LEON3 design make the JTAG Chain to die (this is what is looks
> like for the moment).
>
> The FPGAs on the boards where I see this behaviour are with date codes
> mentioned in
>
> http://direct.xilinx.com/bvdocs/notifications/xcn06018.pdf
>
> but I dont think this could be the issue?
>
> Antti
> 



Article: 104912
Subject: Re: Weird JTAG lockup issue, where is the BUG?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 9 Jul 2006 11:58:00 -0700
Links: << >>  << T >>  << A >>
Rob schrieb:

> I'm not that familiar with Xilinx's FPGA's; but I did have an issue with an
> Altera FPGA that turned out to be power supply related.  The problem was
> that the power-up configuration was unstable, sometimes it would work and
> other times it wouldn't.  But, if I powered up, then initiated a
> configuration (from an on board push-button), it always worked.  This led me
> to look at the power rails. In my case, I had a power supply that was
> generating a non-monotonic rise on VCCint.  Once I fixed the rise so that it
> was smooth the problem went away.
>
> Can you initiate, or re-initiate, the configuration cycle after you are
> powerd up and the voltage rails are stable?  If so, try it, and see what
> happens.  It may give you another clue.
>
> Take care,
> Rob

Hi Rob,

1) I can configure and reconfigure the board with many many different
designs and never see an issue at all.

2) when using one specific design/bitstream then I can configure and
reconfigure any number of times when Xilinx impact is set to perform
configure and verify. Impact even reports programming and verify
success !!

3) using the same bitstream and impact with configure, but no verify
then first configuration attempts says configure error (CRC error) and
after that the JTAG chain is reported as broken before the FPGA. The
power supplies are still proper Voltage and stable and the FPGA does
not get hot. But it needs to be power cycled for the JTAG TAP to come
live again.

I understand that power supply is the most likely issue but why doesnt
the issue never happen when jtag operation is set to
configure_and_verify? and locks up the jtag tap 100% when attempting to
configure without verify?

I bet this remains "Xilinx mystery" forever.

Antti


Article: 104913
Subject: Re: Weird JTAG lockup issue, where is the BUG?
From: Austin Lesea <austin@xilinx.com>
Date: Sun, 09 Jul 2006 12:01:00 -0700
Links: << >>  << T >>  << A >>
Anti,

All devices after Virtex E (Sparta 2E) have no extra current required 
over that which is specified in the data sheet for minimum power on current.

Is it possible that the configuration you are loading requires more 
power than you have available?

I have seen DONE go high, only for the power supply to crash, fold back, 
  and the part starts to reconfigure again.

As for the JTAG state machine, it is definitely possible for it to enter 
a "bad" state from which it may never recover.  It is only with Virtex 
4, and now Virtex 5, that we have worked carefully on the state machines 
to harden them from soft errors, which might place them in an 
unrecoverable state.  Irradiation with neutrons can quickly find those 
hidden bad states!

Austin

Article: 104914
Subject: Re: Weird JTAG lockup issue, where is the BUG?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 9 Jul 2006 12:41:34 -0700
Links: << >>  << T >>  << A >>
Austin Lesea schrieb:

> Anti,
>
> All devices after Virtex E (Sparta 2E) have no extra current required
> over that which is specified in the data sheet for minimum power on current.
>
> Is it possible that the configuration you are loading requires more
> power than you have available?
>
> I have seen DONE go high, only for the power supply to crash, fold back,
>   and the part starts to reconfigure again.
>
> As for the JTAG state machine, it is definitely possible for it to enter
> a "bad" state from which it may never recover.  It is only with Virtex
> 4, and now Virtex 5, that we have worked carefully on the state machines
> to harden them from soft errors, which might place them in an
> unrecoverable state.  Irradiation with neutrons can quickly find those
> hidden bad states!
>
> Austin

Hi Austin,

I also did think there is no extra power surge at configuration on S3.

I do not think the design takes more power then available.

I was just porting LEON3 design onto some new boards to have more
designs for the board test. To my very surprise the LEON3 design never
started up correctly. I did make the design smaller by disabling MMU
and caches and the problem persisted. The desing uses 13% of S3-4000
and is set to run from 25MHz.

All power supplies are rated to 6A. The same board runs succesfully a
Microblaze desing with two separate SDRAM controllers, ethernetand TFT
display cores at 72MHz, I would bet that design should  defenetly burn
more dynamic current than the plain vanilla LEON3
design. Ok I cant measure the LEON3 design power as it never comes up
live. Wrong I can, I have one Memec board with s3-1500 I can load the
design that fails on my board onto memec and measure current and then
measure current on my boards with some design that do work.

That should tell if the boards that fails do work with the current that
the LEON3 design requires.

As of JTAG dead states - that fact that Xilinx has only ironed it out
for V4 and V5 really surprises me. A JTAG TAP isnt rocket sience.

--
I havent been able to test with non JTAG configuration methods yet
maybe the all issue is only with impact software - the JTAG chain
contains a Atmel AT91SAM7S ARM with JTAGSEL=0 eg the ARM ICE JTAG chain
is selected. It is remotly possible that the ARM JTAG is getting messed
up somehow. This could even explain why there is
difference when configuring with verify on and off. Well it means that
I have stumbled into some very nasty Impact bug?

I know that the ARM ICE JTAG is not 100% proper JTAG but as long as
it.. hmm maybe i solved the issue at this very moment, as the ARM JTAG
has a bug that disturbs some JTAG operations when JTAG clock is over
system clock and the Atmel ARM powers up with internal 128KHz clock,
then it is remotly possible it gets upset somehow. As I did not see
problem so far I assumed the ARM BYPASS works at higher speeds also
(but all assumptions are wrong).

If I think of it, then it sounds like that this must be the problem.
Just weird that every other design worked so far and one design doesnt.

Antti


Article: 104915
Subject: Is while loop synthesizable if the number of iterations is known
From: "thejay" <elec.jay@gmail.com>
Date: Sun, 09 Jul 2006 18:40:58 -0400
Links: << >>  << T >>  << A >>
Is while loop synthesizable if the number of iterations is known
If yes then how come for is not synthesizable

I heard for is not synthesizable is that true






Article: 104916
Subject: Re: Is while loop synthesizable if the number of iterations is known
From: Ben Jackson <ben@ben.com>
Date: Sun, 09 Jul 2006 19:26:49 -0500
Links: << >>  << T >>  << A >>
On 2006-07-09, thejay <elec.jay@gmail.com> wrote:
> Is while loop synthesizable if the number of iterations is known
> If yes then how come for is not synthesizable
>
> I heard for is not synthesizable is that true

For constant limits on an integer value it should work:

        integer i;
        always @(posedge clk)
                if (ce && ~rst) begin
                        for (i = 0; i < depth - 1; i = i + 1)
                                fifo[i] <= fifo[i+1];
                        fifo[depth - 1] <= d;
                end

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

Article: 104917
Subject: Re: Weird JTAG lockup issue, where is the BUG?
From: "Rob" <robnstef@frontiernet.net>
Date: Mon, 10 Jul 2006 01:52:22 GMT
Links: << >>  << T >>  << A >>
I didn't think that was the problem, but I thought I would throw it out 
there.  Bizarre problem indeed.  Please post when you find the answer.

"Antti" <Antti.Lukats@xilant.com> wrote in message 
news:1152471480.276262.151590@35g2000cwc.googlegroups.com...
> Rob schrieb:
>
>> I'm not that familiar with Xilinx's FPGA's; but I did have an issue with 
>> an
>> Altera FPGA that turned out to be power supply related.  The problem was
>> that the power-up configuration was unstable, sometimes it would work and
>> other times it wouldn't.  But, if I powered up, then initiated a
>> configuration (from an on board push-button), it always worked.  This led 
>> me
>> to look at the power rails. In my case, I had a power supply that was
>> generating a non-monotonic rise on VCCint.  Once I fixed the rise so that 
>> it
>> was smooth the problem went away.
>>
>> Can you initiate, or re-initiate, the configuration cycle after you are
>> powerd up and the voltage rails are stable?  If so, try it, and see what
>> happens.  It may give you another clue.
>>
>> Take care,
>> Rob
>
> Hi Rob,
>
> 1) I can configure and reconfigure the board with many many different
> designs and never see an issue at all.
>
> 2) when using one specific design/bitstream then I can configure and
> reconfigure any number of times when Xilinx impact is set to perform
> configure and verify. Impact even reports programming and verify
> success !!
>
> 3) using the same bitstream and impact with configure, but no verify
> then first configuration attempts says configure error (CRC error) and
> after that the JTAG chain is reported as broken before the FPGA. The
> power supplies are still proper Voltage and stable and the FPGA does
> not get hot. But it needs to be power cycled for the JTAG TAP to come
> live again.
>
> I understand that power supply is the most likely issue but why doesnt
> the issue never happen when jtag operation is set to
> configure_and_verify? and locks up the jtag tap 100% when attempting to
> configure without verify?
>
> I bet this remains "Xilinx mystery" forever.
>
> Antti
> 



Article: 104918
Subject: Re: Chaos in FF metastability
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 09 Jul 2006 21:21:18 -0500
Links: << >>  << T >>  << A >>

>AH!  We have the first condition for chaotic behaviour, sensitivity to
>initial conditions...  When the input is near the balance point, the
>slightest difference will determine whether the output goes positive or
>negative.  That is a very significant aspect of the circuit.

When I think of chaos, I think of hard to predict systems.  The classic
example is the earth's weather pattern.  We think we can analyze the
local details but we can't predict anything long term.

In the case of metastability, the system eventually stabilizes at
a 1 or 0.  That's two possible states rather than zillions.

Is it called "chaotic" if I can't predict when it will stabilize?

-- 
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: 104919
Subject: Re: PCI IOs, tiofoi, source sampling bypass
From: hmurray@suespammers.org (Hal Murray)
Date: Sun, 09 Jul 2006 21:26:17 -0500
Links: << >>  << T >>  << A >>
>The reason for this requirement is the specification claims that the timing
>budget does not cover the time for the "reflected wave" to return to the
>driving device in time to be properly received by the next clock edge.  As
>you pointed out, it is hard to imagine this being a big issue at 33 MHz, but
>at 133 MHz, I would not dare ignore it.

This gets interesting.

In the old/slow days, PCI was a multi-drop bus system.  If the reflected
wave didn't get back to you, it (most likely) didn't get back to the
chip/card right next to you either.  The timing budged had to cover
that case so you got a free ride.

Are newer/faster PCI systems limited to point-point links rather than
multi-drop busses?  Are there requirements on the driving/source
(termination) impedance to damp out multi-trip reflections?

-- 
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: 104920
Subject: Re: Chaos in FF metastability
From: Phil Hays <Spampostmaster@comcast.net>
Date: Sun, 09 Jul 2006 20:24:34 -0700
Links: << >>  << T >>  << A >>
(Hal Murray) wrote:

>
>>AH!  We have the first condition for chaotic behaviour, sensitivity to
>>initial conditions...  When the input is near the balance point, the
>>slightest difference will determine whether the output goes positive or
>>negative.  That is a very significant aspect of the circuit.
>
>When I think of chaos, I think of hard to predict systems.  The classic
>example is the earth's weather pattern.  We think we can analyze the
>local details but we can't predict anything long term.
>
>In the case of metastability, the system eventually stabilizes at
>a 1 or 0.  That's two possible states rather than zillions.
>
>Is it called "chaotic" if I can't predict when it will stabilize?

No.  Chaotic means that it doesn't stabilize.  A flipflop with chaotic
metastability, if setup or hold times were not honored, could
oscillate without a fixed period until the next clock edge.  This
doesn't seem useful to me, but it is clearly a possibility.  TTL at
least came close to this, as one of the metastable failure modes of at
least some TTL flipflops was an oscillation until the next clock edge.


--
Phil Hays (Xilinx, but speaking for himself)


Article: 104921
Subject: The FFs with synchronous reset perform worse?
From: "Stanley Lee" <lizhongqi@hotmail.com>
Date: 9 Jul 2006 20:35:03 -0700
Links: << >>  << T >>  << A >>
Hi, all:
The FFs can be reset synchronously or asynchronously. And in ASIC
design, the FFs with asynchronous reset will be "smaller". But in FPGA
design, will the FFs with asynchronous reset perform better than the
ones with synchronous reset? Or, is the kind of reset just an "option"
for the FFs instantiated?


Article: 104922
Subject: Re: The FFs with synchronous reset perform worse?
From: mk <kal*@dspia.*comdelete>
Date: Mon, 10 Jul 2006 04:28:38 GMT
Links: << >>  << T >>  << A >>
On 9 Jul 2006 20:35:03 -0700, "Stanley Lee" <lizhongqi@hotmail.com>
wrote:

>Hi, all:
>The FFs can be reset synchronously or asynchronously. And in ASIC
>design, the FFs with asynchronous reset will be "smaller". 

I am not sure why you put it into quotes but this statement is almost
definitely false. I've never seen an ASIC library where the async
reset flops were not larger in area than non-reset flops from which
one usually makes the sync flops. Non-reset flops are also usually
faster and the resulting design is faster again because one usually
has a path in the logic which resets the flop so the sync reset gets
merged with that path.

Article: 104923
Subject: Re: Xilinx Xcell Journal received damaged
From: Zara <dlm0-hbge@dea.spamcon.org>
Date: Mon, 10 Jul 2006 06:54:53 +0200
Links: << >>  << T >>  << A >>
On Sat, 08 Jul 2006 21:36:22 -0000, gavin@allegro.com (Gavin Scott)
wrote:

>So I've been on the mailing list for Xilinx's Xcell Journal glossy 
>magazine for a year or two now, and something I've noticed is that
>EVERY issue I've received is trashed to one degree or another.  The
>covers are torn, the corners crushed or completely folded over, etc.
>
>After 4-5 issues I'm starting to get suspicious that Xilinx has a
>problem with their mailing house rather than that I've just had 
>really bad luck or the postal service is run by Altera or something.
>
>Issue 57 showed up in the last couple weeks, and while attempting to
>browse through it (something made difficult by several parts of the
>cover missing, the lower right corner folded over, and the bottom and
>right middle edges smashed in), I notice that on what's left of the
>"Letter from the Publisher" page, the post office has applied a large
>red stamp mark that reads "Received in damaged condition".  This 
>suggests to me that the problem happened before the magazine reached
>the post office.
>
>So, I thought I would come and ask if this is just me that's gotten
>unlucky or whether other people are having similar issues (pun not
>intended, well, ok, maybe a little).
>
>G.

I receive my copy on Spain with no damage at all. I would blame your
postal service or postal office.

Z.

Article: 104924
Subject: Re: The FFs with synchronous reset perform worse?
From: "Stanley Lee" <lizhongqi@hotmail.com>
Date: 9 Jul 2006 22:45:20 -0700
Links: << >>  << T >>  << A >>

mk =E5=86=99=E9=81=93=EF=BC=9A

> On 9 Jul 2006 20:35:03 -0700, "Stanley Lee" <lizhongqi@hotmail.com>
> wrote:
>
> >Hi, all:
> >The FFs can be reset synchronously or asynchronously. And in ASIC
> >design, the FFs with asynchronous reset will be "smaller".
>
> I am not sure why you put it into quotes but this statement is almost
> definitely false. I've never seen an ASIC library where the async
> reset flops were not larger in area than non-reset flops from which
> one usually makes the sync flops. Non-reset flops are also usually
> faster and the resulting design is faster again because one usually
> has a path in the logic which resets the flop so the sync reset gets
> merged with that path.

Thank you for your answer, and what you say is about ASIC or FPGA? I
want to know the performance of the two kind of FFs in FPGA.

Thank you once again.




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search