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
Hello, I have build a system consisting of two Microblazes connected with an FSL channel. When using the putfsl_interruptable() macro data gets lost. If the FSL FIFO is full sometimes putfsl_interruptable() returns without having written the data to the FSL. I've used the debugger to step through the code at assembler level and nput sometimes fails to set the Carry bit in MSR when the FSL is actually full. So, to me, this looks like a MicroBlaze and/or FSL bug. I have found a post in this newsgroup from Bernhard Sputh who reports quite similiar problems. He could work around this issue by disabling interrupts. Sadly, disabling interrupts while calling the *_interruptable() doesn't help in my case. I'm using the Microblaze Version that comes with EDK 8.1.02. Are there any errata sheets for the FSL and/or Microblaze available? I found no such thing on the Xilinx web site. Best regards, AndreasArticle: 121951
<roche.alexis@gmail.com> wrote in message news:1184578572.283373.72830@22g2000hsm.googlegroups.com... > Hello, > I'm trying to simulate my design in modelsim and i'm trying to find > out if it is possible to choose the set_up delays of the clock signals > in a simulation. Clock signals do not have 'setup delays' > > Indeed in my simulation the clock edge are too fast (0 ns) The 'clock edges' will always be 0ns in simulation. > so it > creates errors in my simulation which will not appears in a real > design due to set_up delays. > Setup times (and hold times) are requirements that must be met in order for the design to work. If you violate the setup or hold time requirements then your design will not be guaranteed to work. From your description, it sounds like the inputs to your design are not meeting the timing requirements relative to your clock. Look at your testbench code that generates the inputs to your design. Are the inputs stable relative to the clock for the entire setup time prior to the clock all the way through to the hold time after the clock? I'm guessing that they're not, the solution is not some 'clock setup delays', the solution is one of the following: - Properly model the other inputs so that they transition at the proper time relative to the clock that will happen in the system (Hint: If those signals are clocked by that same clock signal they will not be transitioning exactly at the rising edge of the clock....they will happen some Tco time later). - If the inputs in your system have no timing relationship relative to the clock then they are asynchronous to the clock in which case your design needs to take that properly into account by synchronizing them. By definition, those synchronizing flip flops will occasionally have their input setup/hold times violated which is OK (which is why the word 'properly' is in the previous sentence in '...properly into account...'. In any case you don't need set_up delays on clock signals....whatever that really is supposed to mean KJArticle: 121952
I have tried to apply all the advice given by Ben Jackson and John-H. So, here is the updated schem & now fully routed board. http://home.peufeu.com/nik/fpga/board_v02/ Thanks a lot ! I guess I've got to order the parts now, check footprints with the real thing... > For a point-to-point solution on a small board, I'd suggest the series > resistors are overkill for data and address lines. If there were > multiple loads, those resistors could be very handy. If the routing > length was 6" or more, those resistors could be very handy. For even a > 200 MHz SRAM interface placed very close to the FPGA, I had no qualms > about point-to-point connections. OK. That's cool, because when putting the SDRAM below the FPGA there isn't much space for resistors... > One additional quick item - how are you hooking up the JTAG? If you're > using the Xilinx programming adapter (I really prefer the Platform Cable > USB) I'd suggest using the connector and pinout that plays nice with the > ribbon cable connection. I have a JTAG parallel port gizmo from Trenz ; it works well and is compatible with the Xilinx tools. I'll use a compatible header on my board so a simple ribbon will work. > If this is board will have very few items produced, I'd also suggest > using a memory that has a JTAG interface such that programming the Flash iMPACT can write the flash via the FPGA's own JTAG, I will use this feature. > and reconfiguring the FPGA on the fly are both done with the same > connect-in and forget-it interface. It may be a few dollars rather than > 50 cents for a chip that gives you the flexibility, but I'd glagly take > a $40 hit to avoid reconnecting those darned header signals over and > over. A quick on-and-off connection with the 1mm spaced ribbon cable is > so much easier than dealing with the flying leads and, perhaps, better > for signal fidelity which can be an issue sometimes. Oh yeah. Flying leads are a pain. How come they could agree on everything in JTAG to make it a standard, except the pinout ???? Regards, PierreArticle: 121953
> - Properly model the other inputs so that they transition at the proper time > relative to the clock that will happen in the system (Hint: If those > signals are clocked by that same clock signal they will not be transitioning > exactly at the rising edge of the clock....they will happen some Tco time > later). That's exactly my problem. In my simulation the edge clock and my signal arrives exactly at the same time. In fact I the signal is an Write of an fifo, and I use a state machine to create a '1' during a period. But When this signal goes '1' to '0' it maps exacly whith the rising'edge of my clock, and I'm writing two data in my FIFO when 1 want just one. And I thinck in a real design i won't append, due to delay in the flip-flop. (Sorry about my English I try to do my best) So if i have understand what you said it not feasible to change 'in modelsim' that, so I need to include delay time in my test-bench? Thancks for your answerArticle: 121954
On Jul 15, 3:21 pm, Weng Tianxiang <wtx...@gmail.com> wrote: > Hi Patrick, > How do I download your script source code? > > At csptool:http://code.google.com/p/csptool/I couldn't fine any > download files. > > Thank you. > > Weng http://code.google.com/p/csptool/source Click on "Subversion repository". Then browse to \trunk\csptool.pl Alternatively, I made an executable available (long overdue): http://csptool.googlecode.com/files/csptool.zip Thanks for your interest Patrick.Article: 121955
Hi,
If you using putfsl_interruptable() then you are using this macro:
#define getfsl_interruptible(val, id) asm volatile
("\n1:\n\tnget\t%0,rfsl" stringify(id) "\n\t" \
"addic\tr18,r0,0\n\t" \
"bnei\tr18,1b\n" \
: "=d" (val) :: "r18")
What this actually does is to use the non-blocking get instruction which
will try to put a value to the FSL but will not stall if it can't.
If it fails due to that the FSL is full it will set the carry flag C in the
MSR register.
The instruction addic r18,r0,0 will add this Carry value to the r18 register
and it will continue to loop until the r18 is zero (Carry = 0).
If you get an interrupt, the interrupt handler must assure that the carry
bit in MSR is restore on the return, otherwise a failed nput will be
consider as a success.
What kind of interrupt_handler are you using?
Göran Bilski
"Andreas Hofmann" <ahnews@gmx.net> wrote in message
news:1jsrm4-9ol.ln1@oscar.lan.andreas-hofmann.de...
> Hello,
>
> I have build a system consisting of two Microblazes connected with an
> FSL channel. When using the Cmacro data gets lost.
> If the FSL FIFO is full sometimes putfsl_interruptable() returns without
> having written the data to the FSL.
>
> I've used the debugger to step through the code at assembler level and
> nput sometimes fails to set the Carry bit in MSR when the FSL is
> actually full. So, to me, this looks like a MicroBlaze and/or FSL bug.
>
> I have found a post in this newsgroup from Bernhard Sputh who reports
> quite similiar problems. He could work around this issue by disabling
> interrupts. Sadly, disabling interrupts while calling the
> *_interruptable() doesn't help in my case.
>
> I'm using the Microblaze Version that comes with EDK 8.1.02. Are there
> any errata sheets for the FSL and/or Microblaze available? I found no
> such thing on the Xilinx web site.
>
>
> Best regards,
> Andreas
Article: 121956PFC wrote: <snip> >> If this board will have very few items produced, I'd also suggest >> using a memory that has a JTAG interface such that programming the Flash > > iMPACT can write the flash via the FPGA's own JTAG, I will use this > feature. <snip> Your schematic shows a JTAG header and an external programming interface header for the ATMEL flash. If you're suggesting that Impact will reach out of the FPGA on the passive serial lines and program the flash there, I don't know the tools like I thought I did. If I do understand the tools, the FPGA can be programmed with the JTAG but the flash will have to be reconnected through your external programming header. If you used a JTAG-compatible memory rather than the economical ATMEL chip, you would have a daisy-chain of the two devices in your JTAG chain. Programming the FPGA or the Flash would be a simple matter of selecting which chip for Impact to target. - John_HArticle: 121957
I am guessing that you are doing a pre-implementation simulation of your
code. These simulation don't have any idea about timing. If you want to
add this information so it makes it easier for you to undestand the results,
add delays in the desired assignments in your code. In the case of Verilog
to add a 3 time unit delay:
always @(posedge clk) begin
if(en)
data_FF <= #3 d;
end
Don't forget to specify what that time unit is (ns or ps) in your file.
Also, note that when your code is synthesized these delays will be ignored.
---Matthew Hicks
>> - Properly model the other inputs so that they transition at the
>> proper time relative to the clock that will happen in the system
>> (Hint: If those signals are clocked by that same clock signal they
>> will not be transitioning exactly at the rising edge of the
>> clock....they will happen some Tco time later).
>>
> That's exactly my problem. In my simulation the edge clock and my
> signal arrives exactly at the same time. In fact I the signal is an
> Write of an fifo, and I use a state machine to create a '1' during a
> period. But When this signal goes '1' to '0' it maps exacly whith the
> rising'edge of my clock, and I'm writing two data in my FIFO when 1
> want just one. And I thinck in a real design i won't append, due to
> delay in the flip-flop.
> (Sorry about my English I try to do my best)
> So if i have understand what you said it not feasible to change 'in
> modelsim' that, so I need to include delay time in my test-bench?
>
> Thancks for your answer
>
Article: 121958On Jul 16, 1:32 am, Peter Alfke <al...@sbcglobal.net> wrote: > Well, so we now have reduced the flaming merciless attacks on Xilinx > to something much simpler: > the problem of obtaining new software, after you failed to back up > your computer properly. Nope. Try reading the guy's post more carefully. He needed a new key to go with the new harddrive. Backups won't usually duplicate the volume serial number. > > have your HD crash, and ask Xilinx for another key for your license so > > you can reinstall on the new drive ... you cann't get one.Article: 121959
I need to generate approximately 1ms delay in Virtex5 -3 FPGA. The fabric clock is running at 200MHz. I was thinking about using 20 bit timer to achieve this as the wait is fairly integarted in the state machine so having a simple counter makes it easy. I basically look for a specific count value in a particular state if not I keep incrementing the count. Is this the right way to achieve the delays? Thanks. WeiArticle: 121960
On Jul 15, 12:49 pm, jon...@gmail.com wrote: > My scope is only 100mhz, but the edges look really sharp to me. I > doubt the jtag circuits are fast enough to respond to anything above > this speed. This has come up before regarding xilinx jtag circuits. Because they are all part of the same chip, the jtag circuit is just as fast as any other part of the chip. So high speed transitions *could* still be a problem. > I was using a home made parallel 3. I know people have tons of trouble > with these, but the data going in/out seems to be really clean. Just > in case, i hooked my board into the jtag chain of digilent nexsys > board with a spartan-3e on it. It also has a integrated usb > programmer. My device was shown in the chain with the same garbage id > i see on my parallel 3. When trying to program the other devices, it > fails, leading me to believe the device cannot enter bypass mode. Can't you borrow a Platform USB jtag cable? Have you tried using debug mode in impact? It allows you to step through the jtag state machine, and do things like enter bypass mode manually. It even has a nice graphical depiction of the state machine. On the other hand, it didn't help me with my problem, but your mileage may vary. > The chip is setup to configure over SPI. CCLK is > going, but cso_b never goes low, and mosi never toggles. I thought my mode pins might be causing in a problem, but in the end, they had no effect. > I've checked the connections a thousand times. Been there, done that. Alan NishiokaArticle: 121961
It might be easier to only allow state transitions when the counter is at a specific value. This will make your state machine more understandable and easier to maintain. ---Matthew Hicks > I need to generate approximately 1ms delay in Virtex5 -3 FPGA. The > fabric clock is running at 200MHz. I was thinking about using 20 bit > timer to achieve this as the wait is fairly integarted in the state > machine so having a simple counter makes it easy. I basically look for > a specific count value in a particular state if not I keep > incrementing the count. > > Is this the right way to achieve the delays? > > Thanks. > > Wei >Article: 121962
> Your schematic shows a JTAG header and an external programming interface > header for the ATMEL flash. If you're suggesting that Impact will reach > out of the FPGA on the passive serial lines and program the flash there, > I don't know the tools like I thought I did. XAPP 445 page 9 seems to hint at this. I could also upload a bitstream containing a bootloader and SPI flash driver, an send configuration via the serial port. I reprogrammed the parallel Flash on my previous FPGA module this way. Can you point to a suitable Flash chip supporting JTAG, just in case ? Thanks. > If I do understand the tools, the FPGA can be programmed with the JTAG > but the flash will have to be reconnected through your external > programming header. If you used a JTAG-compatible memory rather than > the economical ATMEL chip, you would have a daisy-chain of the two > devices in your JTAG chain. Programming the FPGA or the Flash would be > a simple matter of selecting which chip for Impact to target. > > - John_HArticle: 121963
The Xilinx XCS04S would give you the JTAG connections for reprogramming and is certainly supported well by the Impact tools. The Spartan-3E Family Complete Data Sheet's section on Configuration (in the Functional Description) has a direct link to the Platform Flash product page in the Spartan-3E Configuration Mode Options and Pin Settings table. - John_H "PFC" <lists@peufeu.com> wrote in message news:op.tvkbmksacigqcu@apollo13... > >> Your schematic shows a JTAG header and an external programming interface >> header for the ATMEL flash. If you're suggesting that Impact will reach >> out of the FPGA on the passive serial lines and program the flash there, >> I don't know the tools like I thought I did. > > XAPP 445 page 9 seems to hint at this. > I could also upload a bitstream containing a bootloader and SPI flash > driver, an send configuration via the serial port. I reprogrammed the > parallel Flash on my previous FPGA module this way. > > Can you point to a suitable Flash chip supporting JTAG, just in case ? > > Thanks. > > >> If I do understand the tools, the FPGA can be programmed with the JTAG >> but the flash will have to be reconnected through your external >> programming header. If you used a JTAG-compatible memory rather than >> the economical ATMEL chip, you would have a daisy-chain of the two >> devices in your JTAG chain. Programming the FPGA or the Flash would be >> a simple matter of selecting which chip for Impact to target. >> >> - John_HArticle: 121964
On 16 Lip, 15:41, cs_post...@hotmail.com wrote: > On Jul 16, 1:32 am, Peter Alfke <al...@sbcglobal.net> wrote: > > > Well, so we now have reduced the flaming merciless attacks on Xilinx > > to something much simpler: > > the problem of obtaining new software, after you failed to back up > > your computer properly. > > Nope. Try reading the guy's post more carefully. He needed a new key > to go with the new harddrive. Backups won't usually duplicate the > volume serial number. > > > > have your HD crash, and ask Xilinx for another key for your license so > > > you can reinstall on the new drive ... you cann't get one. My $0.02 as a EE student. I hate to work on obsolete hardware. What's a point on studying design on Spartan-I and 4K if You won't find them in real life? I was lucky to start my FPGA adventure with Spartan3 and some older Flex from Altera. I recon that both vendors give decent free tools at least for hardware part. I have yet to try soft cpu cores. @Totally_Lost: I feel Your pain. Being on the verge of loosing your business must be a big deal, but wasn't it partially Your fault? I have notice that vendors tend to warn that some part I going obsolete a long time before it actually happens. You wasn't warned? @Xilinx: Refusing providing a license key to client who has already bought something from You smells fishy. I don't know all the facts so I am not telling it is Your fault, but something doesn't seem to be right.Article: 121965
On Jul 16, 12:32 am, Peter Alfke <al...@sbcglobal.net> wrote: > Well, so we now have reduced the flaming merciless attacks on Xilinx > to something much simpler: > the problem of obtaining new software, after you failed to back up > your computer properly. > What a "tempest in a tea pot", as the British say. > Maybe something can be done about this... > Peter Alfke, from home Peter ... you guys screwed up failing to put XC4K/Spartan support in XST, don't blame me, or the thousands of students with XC4K/Spartan student boards for not getting a license early and sandbagging a copy of the early ISE releases. After all that would be circumvention of your copy protection, would it not? Still doesn't help those students and hobbiests that purchased an XC4K/ Spartan student board after the fact, not knowing there was no longer Xilinx VHDL/Verilog synthesis, does it? In 2003 that WAS a serious problem, still is to some degree today as I see them going thru eBay at the same prices as supported boards on a regular basis. JohnArticle: 121966
On Jul 16, 12:32 am, Peter Alfke <al...@sbcglobal.net> wrote: Also Peter, seems the terms of the ISE license (including the FPGA express) is one year for new designs, and after that limited to support of existing designs? So using it after 2003 for new XC4K/ Spartan designs would be in violation of the license? As of Jan 2004 the Digikey catalog is still selling new XC4K parts, which Xilinx has no Synthesis support for. Tell me those customers got the same value for their dollar that the 2002 and 2003 Digikey customers got. It probably took Digikey a long time to move that inventory Xilinx obsoleted early by withdrawing synthesis support,Article: 121967
>I need to generate approximately 1ms delay in Virtex5 -3 FPGA. The fabric clock is running at 200MHz. I was thinking about using 20 bit timer to achieve this as the wait is fairly integarted in the state machine so having a simple counter makes it easy. I basically look for a specific count value in a particular state if not I keep incrementing the count. > >Is this the right way to achieve the delays? > >Thanks. > >Wei > That should work. Make sure you clear the counter on entry to the waiting state. It is good practice to exit on "greater than or equal to" rather than "equal to" despite the former using slightly more combinatorial logic resources.Article: 121968
Hi,
the first time I discovered this behaviour was in a xilkernel
environment. I have not yet looked in the xilkernel source code, if the
carry bit is saved and restored.
I wrote a small test program which does not use interrupts or the
xilkernel. When I use putfsl_interruptible() it fails realiably. The
MicroBlazes and the supporting system is stripped to bare necessity. The
program and the system.mhs is attached at the end of this post. The
number of cycles between two reads of the FSL by MicroBlaze 0 influences
the number of errors seen.
BTW: It would be nice if the Xilinx documentation states that the
fsl_isinvalid() macro depends on the Carry bit set by the nget()/nput()
macros. When programming on C and not on Assembler level this is, to me,
not obvious.
Andreas.
//-------------- test program ------------------------------------
#include "xparameters.h"
#include "mb_interface.h"
#include "stdio.h"
int main()
{
int max_iteration = 0x10000000;
int error_count = 0;
int i = 0;
int j = 0;
int delay;
microblaze_disable_interrupts();
#ifdef MB0
//-------------- MicroBlaze 0------------------------------------
print("Starting ...\r\n");
while( i < max_iteration )
{
getfsl(j, 0);
for( delay = 3; delay > 0; delay-- )
asm volatile ("nop\n\t");
if( i != j )
{
print("Error at i=0x");putnum(i);print(" j: 0x");putnum(j);
print("\r\n");
i = j;
error_count++;
}
i++;
}
if( error_count == 0 )
print("...finished sucessfully.\r\n");
else
{
print("error_count=0x");putnum(error_count);print("\r\n");
}
#else
//-------------- MicroBlaze 1-------------------------------------
while ( i < max_iteration )
{
putfsl_interruptible(i, 0);
i++;
}
#endif
return 0;
}
//-------------- system.mhs -------------------------------------
##############################################################################
# Created by Base System Builder Wizard for Xilinx EDK 8.1.02 Build
EDK_I.20.4
# Tue Sep 05 11:14:00 2006
# Target Board: Custom
# Family: virtex4
# Device: xc4vfx20
# Package: ff672
# Speed Grade: -10
# Processor: Microblaze
# System clock frequency: 100.000000 MHz
# Debug interface: On-Chip HW Debug Module
# On Chip Memory : 64 KB
#
##############################################################################
PARAMETER VERSION = 2.1.0
PORT fpga_0_RS232_RX_pin = fpga_0_RS232_RX, DIR = I
PORT fpga_0_RS232_TX_pin = fpga_0_RS232_TX, DIR = O
PORT sys_clk_pin = dcm_clk_s, DIR = I, SIGIS = DCMCLK
PORT sys_rst_pin = sys_rst_s, DIR = I
BEGIN opb_opb_lite
PARAMETER INSTANCE = opb_opb_lite_0
PARAMETER HW_VER = 1.00.a
PARAMETER C_DEC0_BASEADDR = 0x40600000
PARAMETER C_DEC0_HIGHADDR = 0x4060FFFF
BUS_INTERFACE SOPB = mb1_opb
BUS_INTERFACE MOPB = mb0_opb
END
BEGIN microblaze
PARAMETER INSTANCE = microblaze_1
PARAMETER HW_VER = 4.00.a
PARAMETER C_USE_FPU = 0
PARAMETER C_DEBUG_ENABLED = 1
PARAMETER C_FSL_LINKS = 1
PARAMETER C_NUMBER_OF_PC_BRK = 2
PARAMETER C_USE_BARREL = 0
PARAMETER C_USE_DIV = 0
PARAMETER C_USE_MSR_INSTR = 0
PARAMETER C_USE_PCMP_INSTR = 0
BUS_INTERFACE ILMB = mb1_ilmb
BUS_INTERFACE DLMB = mb1_dlmb
BUS_INTERFACE SFSL0 = mb0_master_fsl
BUS_INTERFACE DOPB = mb1_opb
BUS_INTERFACE IOPB = mb1_opb
BUS_INTERFACE MFSL0 = mb1_master_fsl
PORT CLK = sys_clk_s
PORT DBG_CLK = microblaze_1_DBG_CLK
PORT DBG_TDI = microblaze_1_DBG_TDI
PORT DBG_TDO = microblaze_1_DBG_TDO
PORT DBG_REG_EN = microblaze_1_DBG_REG_EN
PORT DBG_CAPTURE = microblaze_1_DBG_CAPTURE
PORT DBG_UPDATE = microblaze_1_DBG_UPDATE
END
BEGIN microblaze
PARAMETER INSTANCE = microblaze_0
PARAMETER HW_VER = 4.00.a
PARAMETER C_USE_FPU = 0
PARAMETER C_USE_HW_MUL = 1
PARAMETER C_DEBUG_ENABLED = 1
PARAMETER C_FSL_LINKS = 1
PARAMETER C_USE_BARREL = 0
PARAMETER C_USE_DIV = 0
PARAMETER C_USE_MSR_INSTR = 0
PARAMETER C_USE_PCMP_INSTR = 0
PARAMETER C_NUMBER_OF_PC_BRK = 2
BUS_INTERFACE DLMB = mb0_dlmb
BUS_INTERFACE ILMB = mb0_ilmb
BUS_INTERFACE DOPB = mb0_opb
BUS_INTERFACE IOPB = mb0_opb
BUS_INTERFACE SFSL0 = mb1_master_fsl
BUS_INTERFACE MFSL0 = mb0_master_fsl
PORT CLK = sys_clk_s
PORT DBG_CLK = microblaze_0_DBG_CLK
PORT DBG_TDI = microblaze_0_DBG_TDI
PORT DBG_TDO = microblaze_0_DBG_TDO
PORT DBG_REG_EN = microblaze_0_DBG_REG_EN
PORT DBG_CAPTURE = microblaze_0_DBG_CAPTURE
PORT DBG_UPDATE = microblaze_0_DBG_UPDATE
END
BEGIN opb_v20
PARAMETER INSTANCE = mb1_opb
PARAMETER HW_VER = 1.10.c
PARAMETER C_EXT_RESET_HIGH = 0
PORT SYS_Rst = sys_rst_s
PORT OPB_Clk = sys_clk_s
END
BEGIN fsl_v20
PARAMETER INSTANCE = mb1_master_fsl
PARAMETER HW_VER = 2.00.a
PARAMETER C_EXT_RESET_HIGH = 0
PARAMETER C_FSL_DEPTH = 16
PARAMETER C_USE_CONTROL = 0
PORT FSL_Clk = sys_clk_s
PORT SYS_Rst = sys_rst_s
END
BEGIN bram_block
PARAMETER INSTANCE = mb1_lmb_bram
PARAMETER HW_VER = 1.00.a
BUS_INTERFACE PORTA = mb1_ilmb_port
BUS_INTERFACE PORTB = mb1_dlmb_port
END
BEGIN lmb_bram_if_cntlr
PARAMETER INSTANCE = mb1_ilmb_cntrl
PARAMETER HW_VER = 1.00.b
PARAMETER C_BASEADDR = 0x00000000
PARAMETER C_HIGHADDR = 0x0000FFFF
BUS_INTERFACE SLMB = mb1_ilmb
BUS_INTERFACE BRAM_PORT = mb1_ilmb_port
END
BEGIN lmb_v10
PARAMETER INSTANCE = mb1_ilmb
PARAMETER HW_VER = 1.00.a
PARAMETER C_EXT_RESET_HIGH = 0
PORT LMB_Clk = sys_clk_s
PORT SYS_Rst = sys_rst_s
END
BEGIN lmb_bram_if_cntlr
PARAMETER INSTANCE = mb1_dlmb_cntrl
PARAMETER HW_VER = 1.00.b
PARAMETER C_BASEADDR = 0x00000000
PARAMETER C_HIGHADDR = 0x0000FFFF
BUS_INTERFACE SLMB = mb1_dlmb
BUS_INTERFACE BRAM_PORT = mb1_dlmb_port
END
BEGIN lmb_v10
PARAMETER INSTANCE = mb1_dlmb
PARAMETER HW_VER = 1.00.a
PARAMETER C_EXT_RESET_HIGH = 0
PORT LMB_Clk = sys_clk_s
PORT SYS_Rst = sys_rst_s
END
BEGIN opb_v20
PARAMETER INSTANCE = mb0_opb
PARAMETER HW_VER = 1.10.c
PARAMETER C_EXT_RESET_HIGH = 0
PORT SYS_Rst = sys_rst_s
PORT OPB_Clk = sys_clk_s
END
BEGIN fsl_v20
PARAMETER INSTANCE = mb0_master_fsl
PARAMETER HW_VER = 2.00.a
PARAMETER C_EXT_RESET_HIGH = 0
PARAMETER C_FSL_DEPTH = 16
PARAMETER C_USE_CONTROL = 0
PORT FSL_Clk = sys_clk_s
PORT SYS_Rst = sys_rst_s
END
BEGIN bram_block
PARAMETER INSTANCE = mb0_lmb_bram
PARAMETER HW_VER = 1.00.a
BUS_INTERFACE PORTA = mb0_ilmb_port
BUS_INTERFACE PORTB = mb0_dlmb_port
END
BEGIN lmb_bram_if_cntlr
PARAMETER INSTANCE = mb0_ilmb_cntlr
PARAMETER HW_VER = 1.00.b
PARAMETER C_BASEADDR = 0x00000000
PARAMETER C_HIGHADDR = 0x0000ffff
BUS_INTERFACE SLMB = mb0_ilmb
BUS_INTERFACE BRAM_PORT = mb0_ilmb_port
END
BEGIN lmb_v10
PARAMETER INSTANCE = mb0_ilmb
PARAMETER HW_VER = 1.00.a
PARAMETER C_EXT_RESET_HIGH = 0
PORT SYS_Rst = sys_rst_s
PORT LMB_Clk = sys_clk_s
END
BEGIN lmb_bram_if_cntlr
PARAMETER INSTANCE = mb0_dlmb_cntlr
PARAMETER HW_VER = 1.00.b
PARAMETER C_BASEADDR = 0x00000000
PARAMETER C_HIGHADDR = 0x0000ffff
BUS_INTERFACE SLMB = mb0_dlmb
BUS_INTERFACE BRAM_PORT = mb0_dlmb_port
END
BEGIN lmb_v10
PARAMETER INSTANCE = mb0_dlmb
PARAMETER HW_VER = 1.00.a
PARAMETER C_EXT_RESET_HIGH = 0
PORT SYS_Rst = sys_rst_s
PORT LMB_Clk = sys_clk_s
END
BEGIN opb_uartlite
PARAMETER INSTANCE = mb0_RS232
PARAMETER HW_VER = 1.00.b
PARAMETER C_BAUDRATE = 9600
PARAMETER C_DATA_BITS = 8
PARAMETER C_ODD_PARITY = 0
PARAMETER C_USE_PARITY = 0
PARAMETER C_CLK_FREQ = 100000000
PARAMETER C_BASEADDR = 0x40600000
PARAMETER C_HIGHADDR = 0x4060ffff
BUS_INTERFACE SOPB = mb0_opb
PORT OPB_Clk = sys_clk_s
PORT RX = fpga_0_RS232_RX
PORT TX = fpga_0_RS232_TX
END
BEGIN opb_mdm
PARAMETER INSTANCE = debug_module
PARAMETER HW_VER = 2.00.a
PARAMETER C_MB_DBG_PORTS = 2
PARAMETER C_USE_UART = 0
PARAMETER C_UART_WIDTH = 8
PORT OPB_Clk = sys_clk_s
PORT Dbg_Clk_0 = microblaze_0_DBG_CLK
PORT Dbg_TDI_0 = microblaze_0_DBG_TDI
PORT Dbg_TDO_0 = microblaze_0_DBG_TDO
PORT Dbg_Reg_En_0 = microblaze_0_DBG_REG_EN
PORT Dbg_Capture_0 = microblaze_0_DBG_CAPTURE
PORT Dbg_Update_0 = microblaze_0_DBG_UPDATE
PORT Dbg_Clk_1 = microblaze_1_DBG_CLK
PORT Dbg_TDI_1 = microblaze_1_DBG_TDI
PORT Dbg_TDO_1 = microblaze_1_DBG_TDO
PORT Dbg_Reg_En_1 = microblaze_1_DBG_REG_EN
PORT Dbg_Capture_1 = microblaze_1_DBG_CAPTURE
PORT Dbg_Update_1 = microblaze_1_DBG_UPDATE
END
BEGIN dcm_module
PARAMETER INSTANCE = dcm_0
PARAMETER HW_VER = 1.00.a
PARAMETER C_CLK0_BUF = TRUE
PARAMETER C_CLKIN_PERIOD = 10.000000
PARAMETER C_CLK_FEEDBACK = 1X
PARAMETER C_DLL_FREQUENCY_MODE = LOW
PARAMETER C_EXT_RESET_HIGH = 1
PORT CLKIN = dcm_clk_s
PORT CLK0 = sys_clk_s
PORT CLKFB = sys_clk_s
PORT RST = net_gnd
PORT LOCKED = dcm_0_lock
END
Article: 121969"Totally_Lost" <air_bits@yahoo.com> wrote in message news:1184602468.122241.158000@x35g2000prf.googlegroups.com... > On Jul 16, 12:32 am, Peter Alfke <al...@sbcglobal.net> wrote: > > Also Peter, seems the terms of the ISE license (including the FPGA > express) is one year for new designs, and after that limited to > support of existing designs? So using it after 2003 for new XC4K/ > Spartan designs would be in violation of the license? > > As of Jan 2004 the Digikey catalog is still selling new XC4K parts, > which Xilinx has no Synthesis support for. Tell me those customers got > the same value for their dollar that the 2002 and 2003 Digikey > customers got. It probably took Digikey a long time to move that > inventory Xilinx obsoleted early by withdrawing synthesis support, Are you done with your tirade? If not, I'll happily add you to my kill list. This whole thread is just ridiculous. I can understand the grudge, but move on. Synthesis was available, just not by renewal through Xilinx. Third parties still support the XC4000 series, it just costs money. People who purchase old development boards through eBay should leave nasty feedback to the eBay seller if they're not warned that synthesis support is not available through the free tools. It's not necessarily cause for refund but it's evil to sell something that doesn't have an expected level of support. The poor eBay sellers indirectly get regulated by the buyers. It's not Xilinx's fault if there's a 3rd party purchase that wasn't properly researched. - John_HArticle: 121970
On Jul 11, 7:26 pm, kumar <mailsati...@gmail.com> wrote: > Hello every one, > I donot know if it is the right > forum to post this issue here but thought that people of this group > will have the knowledge of JTAG. > We have designed a board which > contains an ALTERA fpga and an EPROM(EPC2LC20).The design is done with > respect to some existing reference schematics.We have populated our > PCB so as to get the power to all the components and then we have > placed the components making up the JTAG circuitary along with the > FPGA and EPROM. > ,Altera's Byte blaster is being used > which is working fine. have checked all the circuitary which seems to > be alright but we keep getting the error"Unable to access the JTAG > chain".We have also tried the steps in the ALTERAs trouble shooters. > Do we need to proceed in a different > way while programming the chip/EPROM for the first time.And also what > is the passive serial mode in the Quartus tool for programming. Any > help would be highly appreciated.Thanks in advance. comp.arch.fpga would be a more appropriate group. I don't understand "seems to be alright" and "unable to access" in the same sentence. Sounds like your JTAG chain is broken. Have you followed Altera's guidelines? <http://www.altera.com/ literature/hb/cfg/cfg_cf52008.pdf> G.Article: 121971
The ISE Classics release is not a one year license (it's perpetual). Also, I think we sent out a letter to customers telling them they could continue to use their current 4K/Spartan licenses forever. Yes, rehosting the flex license was an issue. We tried, but were unsuccessful, to negotiate that with Synopsys. Steve "Totally_Lost" <air_bits@yahoo.com> wrote in message news:1184602468.122241.158000@x35g2000prf.googlegroups.com... > On Jul 16, 12:32 am, Peter Alfke <al...@sbcglobal.net> wrote: > > Also Peter, seems the terms of the ISE license (including the FPGA > express) is one year for new designs, and after that limited to > support of existing designs? So using it after 2003 for new XC4K/ > Spartan designs would be in violation of the license? > > As of Jan 2004 the Digikey catalog is still selling new XC4K parts, > which Xilinx has no Synthesis support for. Tell me those customers got > the same value for their dollar that the 2002 and 2003 Digikey > customers got. It probably took Digikey a long time to move that > inventory Xilinx obsoleted early by withdrawing synthesis support, >Article: 121972
On 2007-07-16, John_H <newsgroup@johnhandwork.com> wrote: > > Your schematic shows a JTAG header and an external programming interface > header for the ATMEL flash. If you're suggesting that Impact will reach > out of the FPGA on the passive serial lines and program the flash there, > I don't know the tools like I thought I did. I don't know if Xilinx can do that, but there's an Altera megafunction called "Serial Flash Loader" (SFL) which can do that with the Quartus II programming tool. That means you can have just one external header (JTAG) and have access to do direct bitstream loads, signaltap and flash programming. (to the OP: doesn't apply to you, obviously!) -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 121973
> The Xilinx XCS04S would give you the JTAG connections for reprogramming > and > is certainly supported well by the Impact tools. > > The Spartan-3E Family Complete Data Sheet's section on Configuration (in > the > Functional Description) has a direct link to the Platform Flash product > page > in the Spartan-3E Configuration Mode Options and Pin Settings table. OK, I'll include one, found it on DigiKey, it fits nicely. I'm keeping the SPI DataFlash, though, but it will only contain the software code that the BRAM microblaze bootloader will copy into SDRAM, you know the story. I don't know if I will need it though, if the Ethernet driver fits in BRAM, it would be able to load the software from the PC via ethernet on boot, so it'll always be up to date without flashing ! Thanks for the advice !Article: 121974
I got sick of using the impact debug chain and wrote my own software so i could step through the commands in the debugger instead of typing them in one at a time. TDO only clocks when i send a clock which makes me think it is not ringing on tclk. Also, determining the scan chain length would probably fail with bad tclk, as it would report lengths not multiples of 32 bits. I don't have a platform usb cable, but as i said i hooked my board into the scan chain of a working spartan-3 board, which has onboard usb programming and it does the same stuff. I decided to desolder the fpga and put another one on. It looks like the pins in the center of the bga were not completely melted. Is it possible this is caused by inadequate ground? Alan has suggest HSWAP as a potential problem. However, there is data on TDO, if there was a missing pullup, wouldn't TDO be zero all the time? Thank
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