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
Dear
Asking many questions on this board --:
My goal is to get "critical path delay" (or maximum clock frequency)
of simple "register file", as described in the following :
---------------------------
There is a register.
Before register, there is a combinational logic.
After register, there is a combinational logic.
---------------------------
I obtained following 5 different reports.
My question is that which report (ouf of (1),(2),(3a),(3b),(3c) )
represents the most accurate "critical path delay" of my
implementation?
(1) Synthesis report reports :
---------------------------
Minimum period: No path found
Minimum input arrival time before clock: 4.026ns
Maximum output required time after clock: 4.636ns
Maximum combinational path delay: 5.975ns
---------------------------
(2) Asynchronous delay report reports :
---------------------------
The 20 worst nets by delay are:
| Max Delay | Netname |
9.579 ReadRegister1_0_IBUF
8.965 SelectRC_IBUF
8.524 ReadRegister2_0_IBUF
.......
---------------------------
(3) Post Place & Route Static Timing report reports :
---------------------------
(3a)Pad to Pad
--------------------------
Source Pad |Destination Pad| Delay |
ReadRegister1<0>|ReadData1<0> | 10.063|
ReadRegister1<0>|ReadData1<1> | 12.041|
...
---------------------------
(3b) Clock clock to Pad
---------------------------
| clock
| | clock |
Destination | to PAD |Internal Clock(s) | Phase |
ReadData1<0> | 9.365(R)|clock_BUFGP | 0.000|
ReadData1<1> | 9.557(R)|clock_BUFGP | 0.000|
ReadData1<2> | 9.465(R)|clock_BUFGP | 0.000|
........
---------------------------
(3c) Setup/Hold to clock clock
---------------------------
| Setup to | Hold to |
| Clock |
Source | clk (edge) | clk (edge) |Internal Clock(s) |
Phase |
SelectRC | 13.663(R)| -1.584(R)|clock_BUFGP |
0.000|
WriteData<0> | 3.373(R)| -0.104(R)|clock_BUFGP |
0.000|
WriteData<1> | 2.466(R)| 0.711(R)|clock_BUFGP |
0.000|
........
Article: 121976On Jul 16, 10:42 am, "John_H" <newsgr...@johnhandwork.com> wrote: > 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, We can agree to disagree about Xilinx's responsibility to provide full software support for products, both while product is actively on distributor's shelves (such as Digikey), and for a useful life thereafter (3-5 years). Austin's clear assertion is that this level of support is (and was) Xilinx's stated company position and mission, and has been met in an exemplary degree, superior to competitors ... I disagree strongly, with this particular event as clear evidence to the contrary. If I've been inaccurate about this historical issue, please correct the specific points, and I quickly and willingly post a retraction for those points if you are correct. Otherwise, I fully stand by my correction of Austin's less than accurate assertion about Xilinx's past support of it's products and customers. John BassArticle: 121977
On Jul 16, 10:51 am, <steve.l...@xilinx.com> wrote: > 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 Hi Steve, It's quite true that the free ISE download licenses are perpetual (which do not include synthesis support for XC4K and Spartan parts). It's also quite true that non-free ISE licenses with XC4K/Spartan support are not, which was my original assertion you are attempting to deflect by changing the subject to free licenses. All of this would not have been a problem if Xilinx had really lived up to the degree of customer support that Austin asserts is Xlinx's commitment to it's customers, by including support for XC4K and Spartan product lines in XST back in 2003. JohnArticle: 121978
On Jul 16, 9:47 am, Jarek Rozanski <jarek.rozan...@gmail.com> wrote: > 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. The time frame we are discussing is 2003, when XC4K and Spartan parts were still shipping products, but a generation back. The parts were still on distributors shelves, and being sold, well after this abrupt withdrawal of ISE synthesis support. There is still lots of new (old stock) inventory kicking around, partly because of this support issue. > @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? Generally end-of-life warnings happen in stages ... notice to existing customers that production will end, and followed by notice to customers that device support and software support will freeze for a specific product. Normally there is plenty of advance warning for both. The timing for abandoning ISE XC4K/Spartan synthesis support was abrupt, so abrupt, that Xilinx was unable to honor customers license requests during the one year term of the ISE Foundation registration (NOT FREE - a couple grand a seat). Those that purchased the cheaper ISE Alliance license without synthesis support were not affected, as they had already gone out an directly purchased expensive synthesis support from a 3rd party. I posted the letter from XIlinx support refusing to provide a new FPGA Express license key for the 1 year ISE Foundation license I had purchased at the time - it speaks for itself -- I purchased the expensive Foundation package with Xilinx provided synthesis tools (from a 3rd party), and Xilinx failed to deliver the required license. Peter might want to claim that customers losing their key didn't do proper backups, but the truth is that XIlinx did not provide ANY written documentation to customers in advance on how to circumvent the FPGA Express copy protection ... that would probably have been in violation of their contract with that software vendor.Article: 121979
On Jul 15, 3:11 pm, "Marc Battyani" <Marc.Batty...@fractalconcept.com> wrote: > "Ben Twijnstra" <ben.twijns...@gmail.com> wrote > > > > > Marc Battyani wrote: > > >> I've just got a brand new board with a Stratix II S180 on it. Before I > >> power it on, I checked the power supply rails for short-circuits. I get > >> 20 > >> ohms on the 1.8V supply rail and 1.2 Ohms for the 1.2V. 20 ohms does not > >> look like a short but 1.2 is rather small. On those supplies, I only have > >> logic components and decap capacitors, the power supply is on another > >> board. > > >> So any advice before I push a few amps in it? Short or not? > >> (I must say that I'm somewhat stressed by the device price ;-) > > > Marc, > > > 1.2 Ohms is fairly normal for this device. The EP2S90 is about 2 Ohms. You > > should get worried if it goes below 1 Ohm. Had one customer see 0.2 Ohm - > > turned out to be a short beween VCCint and PLL ground. > > Thanks Ben, > > In fact I did found shorts on another board (cf link below). They were all > between pads of the LLM21 decoupling caps and around 0.2-0.3 ohms. BTW I'm > somewhat upset with this, considering that I got the boards inspected > visually and by x-rays at the assembly shop. :( > > http://www.fractalconcept.com/short-pb1.jpg > > Marc Hi Marc, Be thankful that you can actually see the short, and it's not under a part :( Because semi parts are active, their "effective" resistance is a function of the applied "supply" voltage. To look for fab shorts with semi parts loaded you need a very low voltage ohm meter, sub 0.2v so that none of the forward diode junctions will actively conduct, and even then leakage currents can be a problem. You will probably have to build this from something that does a very slow sweep from 0-0.5v (to allow caps to charge and equalize) and plots the on board voltage sweep (sensed by a high impedance amplifier) vs a known good gold board sweep.Article: 121980
On Jul 16, 2:22 pm, Totally_Lost <air_b...@yahoo.com> wrote: > You will probably have to build this from something that does a very > slow sweep from 0-0.5v (to allow caps to charge and equalize) and > plots the on board voltage sweep (sensed by a high impedance > amplifier) vs a known good gold board sweep. current limited to a few hundred ma, and plot voltage/current during sweepArticle: 121981
Wei Chen wrote: > 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 sounds reasonable. Don't forget to reset the counter before entering the state where you delay. Also, you might not need to compare all 20 bits. For instance if you can pick your wait time to be 2**N clocks you can say "if counter(16) = '1'" instead of "if counter = 65536" which will be smaller and faster. -JeffArticle: 121982
On 2007-07-15, Marc Battyani <Marc.Battyani@fractalconcept.com> wrote: > > In fact I did found shorts on another board (cf link below). They were all > between pads of the LLM21 decoupling caps and around 0.2-0.3 ohms. I once found a shorted part when I observed that the voltage rail in question was about 0.3R in the general area but 0.2R across the power pins of one particular part (QS3384, I think it was). I pulled it off and the problem went away. I was surprised at the time that I was able to distinguish proximity to the short with a plain old Fluke 10. With a milliohmmeter it might be even easier. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 121983
steve.lass@xilinx.com wrote: > 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. In the instance mentioned of a new hard drive, surely one can simply edit the HD ID, to match what the license expects ? -jgArticle: 121984
On Jul 16, 2:37 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > steve.l...@xilinx.com wrote: > > 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. > > In the instance mentioned of a new hard drive, surely one can > simply edit the HD ID, to match what the license expects ? Doesn't work. I've tried. -aArticle: 121985
On Jul 16, 11:04 am, jon...@gmail.com wrote: > 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. In my case, part of the JTAG state machine worked fine. I was able to put it into bypass and see bits go in and out, so I assumed all of JTAG was good and something else was bad. I was wrong. Thinking about it more, I figure whoever designed the Spartan-3e didn't design the JTAG block. He just dropped in an existing ip block and added a block with Spartan specific stuff to it. So it is possible for part of the JTAG state machine to work while another part is more touchy about signals. > 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. The more cables you try the better. I still think you should beg/ borrow/steal a platform usb cable (but perhaps I am blinded by the fact it worked for me). > 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? That wasn't me and I don't think HSWAP is a probable problem. In my case I messed with it to no effect. Alan NishiokaArticle: 121986
"Totally_Lost" <air_bits@yahoo.com> wrote in message news:1184610534.931937.71120@z28g2000prd.googlegroups.com... > > John, > > We can agree to disagree about Xilinx's responsibility to provide full > software support for products, both while product is actively on > distributor's shelves (such as Digikey), and for a useful life > thereafter (3-5 years). Austin's clear assertion is that this level of > support is (and was) Xilinx's stated company position and mission, and > has been met in an exemplary degree, superior to competitors ... I > disagree strongly, with this particular event as clear evidence to the > contrary. > > If I've been inaccurate about this historical issue, please correct > the specific points, and I quickly and willingly post a retraction for > those points if you are correct. > > Otherwise, I fully stand by my correction of Austin's less than > accurate assertion about Xilinx's past support of it's products and > customers. > > John Bass I don't dispute the accuracy of your points, just the severity. I appreciate your signing the letter so I can finally tell that this familiar, disturbing anger is from the same individual already in my kill file. To fpga_toys gets added Totally_Lost. I like that these kinds of forums are a way to disseminate information and attain assistance or insights that you can't get from websites. I don't appreciate getting my stomach in a knot because one individual has a massive chip on his shoulder. I appreciate the freedom of this forum to accept that kind of behavior - it's mostly a free society after all. But at least I have the freedom to avoid the hatred being shoved in front of my face. Good luck in your travels, Mr. Bass. - John HandworkArticle: 121987
Alan "> Thinking about it more, I figure whoever designed the Spartan-3e > didn't design the JTAG block. He just dropped in an existing ip block > and added a block with Spartan specific stuff to it. So it is > possible for part of the JTAG state machine to work while another part > is more touchy about signals." That is not how it is done around here. JTAG is a standard, and it has requirements that must be met, in order for the product to be qualified (offered for sale). The team that is responsible for the configuration block of the device, is also responsible for the JTAG. That team MUST meet the standard, as the part will be checked by an outside contractor to insure that it was done right. The JTAG (along with all other configuration interfaces) is not only checked by IC Design, is checked by: production test, the "storage solutions team" (the eeproms and other bitstream storage devices), the ISE promgen, bitgen, and all the software tools folks, and the programming cables development team. The interface to the block is through one, and only one design for input and output: the IOB. These being dedicated pins just means that a lot of the programmable options are hardwired (who has the time to make a new input pin, and a new output pin? and then prove it is 'correct?'). Please do not insult the designers: sure they make mistakes, but when they do, we issue errata. http://www.xilinx.com/xlnx/xweb/xil_publications_display.jsp?iLanguageID=1&category=-1211408&sGlobalNavPick=SUPPORT&sSecondaryNavPick= (3SE errata -- NONE) AustinArticle: 121988
"Andy Peters" <google@latke.net> wrote in message news:1184622931.288181.283710@x35g2000prf.googlegroups.com... > On Jul 16, 2:37 pm, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: >> steve.l...@xilinx.com wrote: >> > 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. >> >> In the instance mentioned of a new hard drive, surely one can >> simply edit the HD ID, to match what the license expects ? > > Doesn't work. I've tried. > You wouldn't find anybody licensing their software keyed to such an easily editable thing if you could change so readily. KJArticle: 121989
Greetings all,
I'm encountering a problem with the lwip network stack. Perhaps someone
can spot what I'm missing.
My hardware is an ML405 board. I'm using essentially the reference PPC
design with the Ethernet replaced with the hard TEMAC core. My software
stack is derived from the TEMAC example design, echo.c (from
ml403_ppc_lwip_temac_fifo_91i.zip on the Xilnx website).
I kept the echo port from the example design, and added a second port
for a command interpreter (behind which the real functions are
implemented; they aren't important for purposes of this question).
===================================
/* Standard */
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include "lwip/sys.h" // threads &c
#include "lwip/sockets.h"
#include "lwip/inet.h"
/*
* Thread for each ECHO connection
*/
void *net_echo_processor(void *arg)
{
int len;
char buf[400];
int s;
// Copy the file descriptor then release it
s = *((int*) arg);
//// sys_sem_signal(echo_launch_sem);
LOG(printf("net_echo_processor: Processing data for connection %d\n",
s));
while((len = read(s,buf,400)) > 0) {
write(s,buf,len);
}
LOG(printf("net_echo_processor: Closing socket\n"));
close(s);
}
/*
* Thread for each Command connection
*/
void *net_command_processor(void *arg)
{
int len;
cmd_t cmd;
char buf[400];
// Copy the file descriptor then release it
cmd.sock = *((int*) arg);
//// sys_sem_signal(command_launch_sem);
// Allocate buffers for command/response data. Allow 1 extra char
// for terminating null.
cmd.state = IDLE;
cmd.c_buf = malloc((CMD_BUFFER_SIZE+1) * sizeof(char));
cmd.c_ptr = cmd.c_buf;
cmd.c_fill = 0;
cmd.r_buf = malloc((CMD_BUFFER_SIZE+1) * sizeof(char));
cmd.tx_buf_idx = TX_BUFFER_NO; // default transmit buffer
// Banner
LOG(printf("net_command_processor: Processing data for connection %d\n",
cmd.sock));
len = sprintf(buf, "# foo Adapter\r\n"
"# Ethernet Interface\r\n"
"# Version %d.%d.%d\r\n",
VER_MAJOR, VER_MINOR, VER_BUILD);
write(cmd.sock, buf, len);
if ((cmd.c_buf == NULL) || (cmd.r_buf == NULL)) {
len = sprintf(buf, "er 5 ER_NOMEM # No Memory for command struct!\r\n"
"## Aborting...\r\n\r\n\r\n");
write(cmd.sock, buf, len);
close(cmd.sock);
free(cmd.c_buf);
free(cmd.r_buf);
return;
} else {
len = sprintf(buf, "st TBD TBD TBD # Status not yet implemented\r\n");
write(cmd.sock, buf, len);
}
// Initialization complete
// Loop repeatedly, get buffers of data and call the command parser
// Note c_buf is the start of the command buffer, and c_ptr is the
// start of where the read is allowed to put data (there may be a
// partially processed command in the buffer).
while((len = read(cmd.sock,cmd.c_ptr,
(CMD_BUFFER_SIZE-(cmd.c_ptr-cmd.c_buf)))) > 0) {
//write(s,buf,len);
cmd.c_fill += len;
cmd.c_ptr = &cmd.c_buf[cmd.c_fill];
*(cmd.c_ptr) = '\0';
parse_command(&cmd);
// Check for exit
if (cmd.state == LNK_CLOSE)
break;
}
// Connection closed, exit
LOG(printf("net_command_processor: Closing socket\r\n"));
free(cmd.c_buf);
free(cmd.r_buf);
close(cmd.sock);
}
/*
* Socket listeners
*
*/
void *net_echo_listener(void *arg)
{
int sock, s;
int len;
struct sockaddr_in addr, rem;
// Initialize the protection of 's' to "locked"
//// echo_launch_sem = sys_sem_new(0);
LOG(printf("net_echo_listener: Creating socket\n"));
sock = socket(AF_INET, SOCK_STREAM, 0);
LOG(printf("net_echo_listener: Doing bind\n"));
addr.sin_family = AF_INET;
addr.sin_port = htons(ECHO_PORT);
addr.sin_addr.s_addr = INADDR_ANY;
bind(sock, (struct sockaddr *)&addr, sizeof(addr));
LOG(printf("net_echo_listener: Listening\n"));
listen(sock, 5);
while(1) {
len = sizeof(rem);
s = accept(sock, NULL, NULL);
// s = accept(sock, (struct sockaddr *)&rem, &len);
LOG(printf("net_echo_listener: Accepting new connection\n"));
// Thread is expected to release protection for 's' once it's copied
//// sys_thread_new(net_echo_processor, &s, 7);
net_echo_processor(&s);
// Wait until thread is done initializing and re-protect 's'
//// sys_sem_wait(echo_launch_sem);
}
}
void *net_command_listener(void *arg)
{
int sock, s;
int len;
struct sockaddr_in addr, rem;
// Initialize the protection of 's' to "locked"
//// command_launch_sem = sys_sem_new(0);
LOG(printf("net_command_listener: Creating socket\n"));
sock = socket(AF_INET, SOCK_STREAM, 0);
LOG(printf("net_command_listener: Doing bind\n"));
addr.sin_family = AF_INET;
addr.sin_port = htons(COMMAND_PORT);
addr.sin_addr.s_addr = INADDR_ANY;
bind(sock, (struct sockaddr *)&addr, sizeof(addr));
LOG(printf("net_command_listener: Listening\n"));
listen(sock, 5);
while(1) {
len = sizeof(rem);
s = accept(sock, NULL, NULL);
// s = accept(sock, (struct sockaddr *)&rem, &len);
LOG(printf("net_command_listener: Accepting new connection\n"));
// Thread is expected to release protection for 's' once it's copied
//// sys_thread_new(net_command_processor, &s, 7);
net_command_processor(&s);
// Wait until thread is done initializing and re-protect 's'
//// sys_sem_wait(command_launch_sem);
// LOG(printf("net_command_listener: Launched new command processor\n"));
}
}
/*
* Network subsystem main entry point
*
* - Initialize LwIP and the TEMAC.
* - Register IP address
* - Launch service listener threads
*
* Initialization assumes only one network interface implemented.
*
*/
void *network_main(void *arg)
{
/*
* Initialize network hardware and TCP stack
*
*/
if (network_init()) {
LOG(printf("network_main: Initialization failed!\n"));
exit(-1);
} else {
LOG(printf("network_main: Network Initialized.\n"));
}
/*
* Launch service threads
*/
sys_thread_new(net_echo_listener, 0, 7); // lowish priority
sys_thread_new(net_command_listener, 0, 7); // lowish priority
/*
* Exit, nothing left to do
*/
}
====================================
The module entry point, network_main() is a thread started after
xilkernel and lwip are initialized. The network_init() function
initializes the TEMAC hardware, and is lifted from the example echo.c.
LOG() is a wrapper around printf() to assert a semaphore while printing
in order for messages to not step on each other. parse_command() is
where the actual work happens.
I use a stock linux telnet to access the echo and operation ports. The
echo port works as expected. So does the "command" port. If I
disconnect by using the Telnet escape sequence (i.e. initiate the
disconnect from the telnet client end) I can reconnect with no trouble.
However one of the operations behind parse_command() is supposed to
result in a disconnect - in the loop in net_command_processor()
parse_comand() sets cmd.state to LNK_CLOSE, resulting in the loop
exiting and closing the socket handle. When that happens, neither the
command port nor the echo port can be accessed any longer. It's as
though lwip is well and truly crashed.
A secondary, and possibly related problem is I thought the parameter 5
in listen() allows up to 5 connections. Only one connection is possible.
From my approach to the problem you can easily tell my experience doing
sockets programming is limited. I'd appreciate any clues as to what
might be going wrong, or at least where I could try looking.
Thanks in advance!
ken
Article: 121990I have been trying chipscope from within XPS 9.1.03i on a ML403. I can connect up the ILA sucessfully and can capture and display signals. I can also instantiate and build and run the PLB IBA core. But when I run chipscope analyzer, it just displays DataPort[0]...DataPort[N]. Can someone clue me in on how to get lables like "address bus", "data bus" and various control signal names displayed when using the PLB IBA? thanks, -JeffArticle: 121991
Hi all, Anyone know the differences between Xilinx System Generator and Simulink HDL Coder? Thanks a lot. RichieArticle: 121992
Hello, I have been trying to figure out why the current draw of an XC9536 (not -XL) chip is so high. Xilinx has been of some help, but can't explain why the current I'm seeing (now 70 - 95 mA) is wildly higher than predicted by their formula in the data sheet. I have used these chips before in several products, although I only used a small part of the available logic. In this application I am using practically all of the available logic (all registers and all macrocells). I have set the default to all macrocells at low power, and enable feedback to macrocells and I/O, and this has helped bring it down from 112 mA to 70 - 95 mA (varies from chip to chip and with different configs). The chip is doing exactly the logic I have coded for it, I can find no loads on any outputs, I have even made up a board with only the CPLD on it to read the current accurately. I have all unused I/O pads set to use ground by default to avoid floating inputs. I am using a 5 V chip here because the FET driver this feeds signals to is a TTL-level device and the 3.3 V levels would leave logic margins pretty thin. I could use an XC9536XL, but the current draw on those (by formula) is not much less than the 5 V 9536, so I can't assume much reduction there, and I'd need an extra regulator. Does anybody have any experience with the 5 V 95xx line, and how the data sheet formula compares to actual current consumption? (Oh, the formula predicts about 30 mA current draw, practically all static as the clock is 10 MHz.) My results show it is all static, if I stop the clock current drops by about 3 mA. And, I have no static loads on the outputs, just CMOS inputs to the FET driver, so it has to be all static draw in the CPLD logic core. (When I erase the part, the current draw goes down to ~20 mA.) Thanks in advance for any experience with this, JonArticle: 121993
"John_H" <newsgroup@johnhandwork.com> writes: > My ohmmeter walked away at work, besides - I'd need an ohmmeter to check my > ohmmeter. Don't they have high impedance outputs even when the resistance > measurement goes to the 0-20 ohm range? No.Article: 121994
On 15 Jul., 16:00, Andreas Hofmann <ahn...@gmx.net> wrote: > Hofjue schrieb: > > > On 9 Jul., 13:15, "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote: > >> Each FSL port has one input connection (slave) and one output connecti= on > >> (master). > >> So with 8 FSL ports, you can connect from one MicroBlaze to eight other > >> MicroBlazes. > > >> This should be enough for your system. > > >> G=F6ran Bilski > > > Yes, that's right. But it doesn't work when MicroBlaze Nr. 3 should > > communication with MicroBlaze Nr. 2 - or? In my opinion the only > > solution in this configuration is to use a token ring communication. > > But then it must be a cyclic communication and not an interrupt driven. > > Each MicroBlaze has 8 FSL-Ports. So if you have up to 9 MicroBlazes you > can connect every MicroBlaze with every other. > > Andreas OK - I see. There are eight input AND eight output ports so it's possible to connect 9 MicroBlazes with each other. Thanks for your explanations. The advantage of my solution is, that there is only one interrupt source and all processors can handle it in the same way.Article: 121995
Jon Elson wrote: > Hello, > > I have been trying to figure out why the current draw of an XC9536 (not > -XL) chip is so high. Xilinx has been of some help, but can't explain > why the current I'm seeing (now 70 - 95 mA) is wildly higher than > predicted by their formula in the data sheet. I have used these chips > before in several products, although I only used a small part of the > available logic. In this application I am using practically all of the > available logic (all registers and all macrocells). I have set the > default to all macrocells at low power, and enable feedback to > macrocells and I/O, and this has helped bring it down from 112 mA to > 70 - 95 mA (varies from chip to chip and with different configs). > The chip is doing exactly the logic I have coded for it, I can find no > loads on any outputs, I have even made up a board with only the CPLD on > it to read the current accurately. I have all unused I/O pads set to > use ground by default to avoid floating inputs. > > I am using a 5 V chip here because the FET driver this feeds signals to > is a TTL-level device and the 3.3 V levels would leave logic margins > pretty thin. I could use an XC9536XL, but the current draw on those (by > formula) is not much less than the 5 V 9536, so I can't assume much > reduction there, and I'd need an extra regulator. > > Does anybody have any experience with the 5 V 95xx line, and how the > data sheet formula compares to actual current consumption? (Oh, the > formula predicts about 30 mA current draw, practically all static as the > clock is 10 MHz.) My results show it is all static, if I stop the clock > current drops by about 3 mA. And, I have no static loads on the > outputs, just CMOS inputs to the FET driver, so it has to be all static > draw in the CPLD logic core. (When I erase the part, the current draw > goes down to ~20 mA.) > > Thanks in advance for any experience with this, So you are saying the device is 100% functional, when programmed ? How many devices have you checked ? The symptoms suggest a shorted pin, or bad drive (not Vdd, or Vss) you could try the same code, but with all outputs connected to an OE on one of your spare IOs, and see if the Icc changes on OE. It it does, there is output contetion somewhere. -jgArticle: 121996
On 17 Jul, 05:28, Jeff Cunningham <j...@sover.net> wrote: > I have been trying chipscope from within XPS 9.1.03i on a ML403. I can > connect up the ILA sucessfully and can capture and display signals. I > can also instantiate and build and run the PLB IBA core. But when I run > chipscope analyzer, it just displays DataPort[0]...DataPort[N]. Can > someone clue me in on how to get lables like "address bus", "data bus" > and various control signal names displayed when using the PLB IBA? > > thanks, > -Jeff Jeff, I know if you have used the chip scope core inserter you can import the project file (*.cdc) into chipscope analyser and the signal names will be imported into the analyser. I have not used the chip scope core generator in a long time but I beleive there is a similar option to "generate bus / signal name example File (*.cdc) " which you can modify to include the signal names as connected and then import it in the a similar way. Hope this helps AdamArticle: 121997
In article <XvTmi.11712$bz7.7937@newssvr22.news.prodigy.net>, "KJ" <kkjennings@sbcglobal.net> writes: |> You wouldn't find anybody licensing their software keyed to such an easily |> editable thing if you could change so readily. It did work in FAT16/32-times, though, where you could either lock your FlexLM license to the Ethernet card's MAC address (which neither is unchangeable, btw.) or the HDD-ID. This was common sports when vendors changed from dongles (which could be easily carried home to pursue work there, then bring back the dongle to work next day) to node-locked licenses. I knew quite a number of people whose machines' HDDs magically occured to have same IDs... RainerArticle: 121998
Hi all, First of all I just joined this group so let me salute all members !! I have a request and I would be happy is someone could help. You all probably know that embedded systems are more and more considered as hot topics to be though at universities. I will be in charge of managing a complete course for graduate students on embedded system with a focus on software engineering and operating systems for embedded platforms. Since having only a theoretical course is quite a boring activity : ) I am looking for the best platform students can experiment and play with (doing labs, projects and so on) Obviously, free and open source platforms are privileged since this is an education purpose in a university that cannot afford paying money for licences; or even managing a complex relation with an industrial partner with some 'discounts' on licences. So if anyone has a suggestion I would be happy to know about it. At the end of the process, I'll send a table summarising all the suggestions so other people/teachers could benefit from it. Kind regards,Article: 121999
"gouaich" <gouaich@lirmm.fr> wrote in message news:1184664343.181526.257550@i38g2000prf.googlegroups.com... > > > So if anyone has a suggestion I would be happy to know about it. At > the end of the process, I'll send a table summarising all the > suggestions so other people/teachers could benefit from it. > > Kind regards, > http://www.xilinx.com/univ/ http://www.altera.com/education/univ/unv-index.html http://www.latticesemi.com/support/universityprogram/index.cfm?source=topnav HTH., Syms.
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