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
Martin Schoeberl wrote: > I've uploaded the first draft of the paper: > http://www.jopdesign.com/doc/simpcon_date.pdf > > It's still very similar to the SimpCon definition > at opencores.org. Comments are very welcome. > > To KJ and Tommy: I've added you both in the > Acknowledgments. I hope this is ok with you ;-) I fail to see what's "controversial" about our discussion. Maybe you meant "heated". As a reviewer (I used to be academic) I'd be very concerned that you fail to disclose that SimpCon is single-master only, and thus not a full alternative to the others listed. TommyArticle: 107376
Austin Lesea wrote: > Unfortunately, once the via and trace L is large, there is no way to > make the noise less, withpout making a whole new pcb (re-layout). > > More that once we have had to inform a customer that there is "no hope" > for their pcb because the series L in their layout is dominant, and > there is no way to reduce it. This is certainly true, and been the cause for more than a few re-layouts. At the same time, the chip carrier PCB in most BGA packages also has via's (probably a lot smaller) which add to the series L which are beyound your control, so you only have half, or less of the series L variable in your control. This is even more difficult with older BG series parts where there are also bonding wires in the equation. The only reason for stacking a mix of caps in checkout, is just to verify that it's not a bulk capacitance problem. It would be nice if Xilinx specified both the R and L for these chip carrier PCB's vias/traces, along with chip carrier interplance capacitance, and current profiles to better model both power system performance, and I/O performance. Or at least gave firm numbers on what the user PCB values can be, before the combine result would be unstable by design.Article: 107377
Hi all, Now, I am trying to using Jroute2 to do some routing things. But I am blocked by some questions. 1\ find all the connections to an output of a slice, for example, all the connections to CLB(4,0,S0_XQ), 2\record all the sinks of the src:CLB(4,0,S0_XQ) 3\ using reverseUnroute to unroute all these connections. 4\ rebuild all the connections to a new src CLB(4,2,S0_XQ) I have done the first three steps successfully, but in the forth step, I find something unusual: there used to be a connection form CLB(4,0,S0_XQ) to CLB(4,3,S1_F1), but after I rebuild the connection to a new src CLB(4,2,S0_XQ), the connection turn out to be from CLB(4,2,S0_X) to CLB(4,3,S1_F1). All I did was changing the src pin(from CLB(4,0,S0_XQ) to CLB(4,2,S0_XQ)),I have never change the resource. I want to know what happened? Why does the connection change by itself? I am looking forward to receive you reply! Many thanks and best regards! Sincerely NickyArticle: 107378
http://www.xilinx.com/bvdocs/userguides/ug112.pdf May be useful for those who are curious about our modeling our packages. For full E&M models (complete geometric stackup, etc.) please work with your local FAE. AustinArticle: 107379
Newbie alert... I would like to drive my Spartan 3 design with inputs from a 5V source. I've been unable to find anything in the Spartan 3 datasheet that lets me know if this is do-able. (The signal will be coming fom the parallel port on my laptop, which I suspect probably is 3.3V but I want to be on the safe side.) Any tips are appreciated. Thanks, -NevoArticle: 107380
Hi all,
I'm trying to implement a correlator as a coprocessor on the FSL bus.
The first thing I've done is generate the FSL example using the create
peripheral wizard in EDK 8.1 and hooked it up to the MicroBlaze. When
I do a blocking write or read the MB stalls - my understanding is that
this will happen if the FSL FIFO is full or empty respectively, but it
happens the first time I write to it, so the FIFO should not be full.
If I use non-blocking reads and writes and check the error and invalid
flags after each one using fsl_isinvalid() and fsl_iserror() - see code
below - everything seems normal but the output is always zero. Am I
implementing the error checking macros correctly?
#define write_into_fsl(val, id) nputfsl(val, id)
#define read_from_fsl(val, id) ngetfsl(val, id)
#define WRITE_FSL_TEST_0(val) write_into_fsl(val,
XPAR_FSL_FSL_TEST_0_INPUT_SLOT_ID)
#define READ_FSL_TEST_0(val) read_from_fsl(val,
XPAR_FSL_FSL_TEST_0_OUTPUT_SLOT_ID)
void fsl_test_app(
unsigned int* input_0, /* Array size = 2 */
unsigned int* output_0 /* Array size = 2 */
)
{
int i;
Xuint8 is_error = 0;
Xuint8 is_valid = 0;
print("Entering fsl_test_app \r\n");
//Start writing into the FSL bus
for (i=0; i<2; i++)
{
WRITE_FSL_TEST_0(input_0[i]);
fsl_iserror(is_error);
xil_printf("error post: %d \r\n", is_error);
fsl_isinvalid(is_valid);
xil_printf("valid post: %d \r\n", is_valid);
}
print("Finished Write \r\n");
is_error = 0;
is_valid = 0;
//Start reading from the FSL bus
for (i=0; i<2; i++)
{
READ_FSL_TEST_0(output_0[i]);
fsl_iserror(is_error);
xil_printf("error post: %d \r\n", is_error);
fsl_isinvalid(is_valid);
xil_printf("valid post: %d \r\n", is_valid);
}
}
I added external ports to the FSL core to check the reset polarity and
monitor the state machine - the core is not being held at reset, but
always sits in the Idle state. This, coupled with the blocking
instruction problems seems to indicate an issue with the FSL FIFO
perhaps (I have tried both BRAM and non-BRAM FIFO implementations)?
If anyone has any ideas on what might be going wrong your help would be
much appreciated...
Cheers,
David
Article: 107381Patrick, Congrats on solving your problem! Thanks to Peter for helping you and thanks to you for reporting the solution. I will surely be looking into this thread next time I decide to use the UC2 design. /MikhailArticle: 107382
"Nevo" <nevo_n@hotmail.com> wrote in message news:zwrIg.2012$XD1.1382@trnddc01... > Newbie alert... > > I would like to drive my Spartan 3 design with inputs from a 5V source. > I've been unable to find anything in the Spartan 3 datasheet that lets me > know if this is do-able. (The signal will be coming fom the parallel port > on my laptop, which I suspect probably is 3.3V but I want to be on the > safe side.) > > Any tips are appreciated. > > Thanks, > > -Nevo I think I wrote this a little too hastily. I'm using the Digilent Spartan 3 starter board and would like to drive my design with the parallel port of my computer with as few (hopefully no) external parts as possible. All the IO banks are using 3.3V reference. If there's a particular configuration of the I/O pins that could tolerate a 5V input, I'd appreciate a short explanation. Meanwhile I'll keep reading the datasheet. Thx, -NevoArticle: 107383
From the wave, I find the start,rfd,busy,edone,done and the dv are the same as the datesheet shown, but the xk_index is wrong, it just shows 0,64,128,192,256....,960,why? where are the other values? Who has ever met this problem?I would appreciate your help very much.Article: 107384
"Nevo" <nevo_n@hotmail.com> wrote in message news:zwrIg.2012$XD1.1382@trnddc01... > Newbie alert... > > I would like to drive my Spartan 3 design with inputs from a 5V source. > I've been unable to find anything in the Spartan 3 datasheet that lets me > know if this is do-able. (The signal will be coming fom the parallel port > on my laptop, which I suspect probably is 3.3V but I want to be on the > safe side.) > > Any tips are appreciated. > > Thanks, > > -Nevo Hm... I found http://direct.xilinx.com/bvdocs/appnotes/xapp179.pdf, which lists the 5V tolerant SelectIO standards for the Spartan 2 family (and implicitly says none of the standards are 5V tolerant in the Spartan 2E family), but I'm unable to find a simlar reference for the Spartan 3 family. Table 27, Absoulte Maximum Ratings under DC Electrical Characteristics, suggests that putting 5V into the chip is a no-no. Hm; I think I'm going to answer my own question here by pointing myself to XAPP429 and a whole host of archived messages in comp.arch.fpga.Article: 107385
When I use the xfft2.0 core to simulate a 1024_point FFT by the ModelSim. Why does the FFT's behavioral simulation fail with block RAM address errors, # **Warning:Undefined input WEA. Setting output DOUTA to X # Time: 22600 ps Iteration: 2 Instance: /topo/xlxi_1/xlxi_1/u0/arch_b/xfft_inst/dpm0/dpm_inst # ** Warning: Invalid address ADDRA : UUUU1010. Entire memory contents will be set to 'X'. # Time: 22600 ps Iteration: 2 Instance: /topo/xlxi_1/xlxi_1/u0/arch_b/xfft_inst/dpm0/dpm_inst # ** Warning: Undefined input ADDRB. Setting output DOUTB to X # Time: 22600 ps Iteration: 2 Instance: /topo/xlxi_1/xlxi_1/u0/arch_b/xfft_inst/dpm0/dpm_inst From the wave, I find the start,rfd,busy,edone,done and the dv are the same as the datesheet shown, but the xk_index is wrong, it just shows sixteen numbbers: 0,64, 128,192,256....,960, why? where are the other values? Who has ever met this problem?I would appreciate your help very much.Article: 107386
Austin Lesea wrote: > To the subject at hand: placing additional caps across existing caps > does not reduce the noise (unless the dominant cause is lack of adequate > capacitance). > > The reason why the noise is bad is that the L (as in Ldi/dt) is most > likely the largest, and most dominant factor, in the form of the via and > traces to the bypass capacitor. > > Many times people have placed additional caps on top of the the existing > caps and wondered why the noise is not reduced: well, you did not > change the L in the equation, did you. So why did you expect V to change? > > You may have moved the resonant frequency (more often not), but often > people make the mistake of assuming that a 0.1uF requires a 0.01uF and a > 0.001uF in parallel. You can see that if the series L is dominant, you > haven't even moved the frequency by more than a few percent by the small > amount of additional capacitance. What do you think about the idea that if the caps are connected directly to good low impedance power planes that the location of the caps are not critical at all. I have been discussing this in comp.arch.embedded and have not gotten much negative feedback except some claim that more is always better and that multiple values are not needed. A recent SI/EMI class I took says that you can put a relatively small number of caps pretty much anywhere on the board as long as they are coupled to the power planes with no traces, just the via. This gives a very low impedance connection to the planes and the planes give a very low impedance connection to the chip. It was also shown that to get a low impedance over a broad bandwidth multiple values are needed to push the impedance down and the parallel resonance up. High loss capacitors (X7R/X5R vs. C0G) were also recommended to reduce the signficance of the parallel resonance. Does any of this sound correct to you? It was sure convincing in the class and appears to be a very sure way of getting low noise on the power planes and thereby on the chip power pins!Article: 107387
rickman wrote: > What do you think about the idea that if the caps are connected > directly to good low impedance power planes that the location of the > caps are not critical at all. I have been discussing this in > comp.arch.embedded and have not gotten much negative feedback except > some claim that more is always better and that multiple values are not > needed. On proto boards I'm always worried about process controls, and frequently avoid flying probe testing since it only tests a small number of the connections anyway. One of the concerns has always been plating managment, so where I can on proto (and most production boards) I still place the caps across the pwr/gnd vias when I can, simply to take the via/plane plating reliability out of the question. Stacking caps on problem boards, is just a second check, as high frequency caps are the only thing at the pads normally, so a little bulk stacked on it just takes the via plating out of the question a bit. On production boards, the vendors will generall work with you to optimize plating density across the board, so it's much less of a problem.Article: 107388
Nevo wrote: > "Nevo" <nevo_n@hotmail.com> wrote in message > news:zwrIg.2012$XD1.1382@trnddc01... > > Newbie alert... > > > > I would like to drive my Spartan 3 design with inputs from a 5V source. > > I've been unable to find anything in the Spartan 3 datasheet that lets me > > know if this is do-able. (The signal will be coming fom the parallel port > > on my laptop, which I suspect probably is 3.3V but I want to be on the > > safe side.) > > > > Any tips are appreciated. > > > > Thanks, > > > > -Nevo > > Hm... I found http://direct.xilinx.com/bvdocs/appnotes/xapp179.pdf, which > lists the 5V tolerant SelectIO standards for the Spartan 2 family (and > implicitly says none of the standards are 5V tolerant in the Spartan 2E > family), but I'm unable to find a simlar reference for the Spartan 3 family. > > Table 27, Absoulte Maximum Ratings under DC Electrical Characteristics, > suggests that putting 5V into the chip is a no-no. > > Hm; I think I'm going to answer my own question here by pointing myself to > XAPP429 and a whole host of archived messages in comp.arch.fpga. You need some sort of interface if you want to use 5V I/O with the Spartan 3. You have lots of options. LeonArticle: 107389
fpga_toys@yahoo.com wrote: > rickman wrote: > > What do you think about the idea that if the caps are connected > > directly to good low impedance power planes that the location of the > > caps are not critical at all. I have been discussing this in > > comp.arch.embedded and have not gotten much negative feedback except > > some claim that more is always better and that multiple values are not > > needed. > > On proto boards I'm always worried about process controls, and > frequently avoid flying probe testing since it only tests a small > number of the connections anyway. One of the concerns has always been > plating managment, so where I can on proto (and most production boards) > I still place the caps across the pwr/gnd vias when I can, simply to > take the via/plane plating reliability out of the question. Stacking > caps on problem boards, is just a second check, as high frequency caps > are the only thing at the pads normally, so a little bulk stacked on it > just takes the via plating out of the question a bit. > > On production boards, the vendors will generall work with you to > optimize plating density across the board, so it's much less of a > problem. If you have problems with via plating, don't you have much bigger problems to worry about than cap placement?Article: 107390
rickman wrote: > If you have problems with via plating, don't you have much bigger > problems to worry about than cap placement? On production boards, it's simply not acceptable. On proto boards, it's only a problem for high current vias (pwr/gnd), which is largely avoided if that's where the caps are too, since it averages out the current spikes and reduces any voltage drop across the bad plate. Even then, the few places that it was a problem at all, where the small BGA vias ... everything else is large enough you never see it.Article: 107391
rickman wrote: > If you have problems with via plating, don't you have much bigger > problems to worry about than cap placement? I suppose you can always break out the micro/milli ohm meter and double check every power ground via to plane .... but it's just easier to add bulk caps as a check for problem boards, since the BGA is already mounted anyway, and no way to reliably ohm it.Article: 107392
KJ wrote: > Rather than posting code, I'll refer to yours since it is roughly along > the lines of what I do. Instead I'll hope that my explanation is clear > enough that one can follow my reasoning (whether you agree or disagree > with it) without any more than occasional snippets of code. > [snip] > Combinatorial logic is implemented using concurrent statements outside > the process. When implemented inside the process I have to think too > hard and scroll back to remember if the usage of variable 'x' in this > particular case is the input or the output of the flop. Call me lazy > on this one if you want. This is what I use as well, also avoiding combinatorial processes. Their merit is probably faster simulation time, but it comes at the price of inferior readability and those "latch avoidance" side effects. > > I only use variables like C language macros. In other words if I want > a shorthand way of referring to a hunk of logic, I'll define the > equation for the variable and it will almost always be right at the > very top of the process, then I'll use it wherever....and that would > only be because for some reason it wasn't looking right as a > combinatorial function concurrent statement for some reason. Variables > when added to the Modelsim wave window do not show any of the signal > history, signals do not have that limitation. If it's a 'simple' > function that is being implemented by the variable then this is not a > big deal, if the function being implemented is rather tricky then being > able to display the history can be very important. If I don't, then I > have to restart the simulation adding the variables to the wave window > before I say 'run'....wasted time...and if those variables then lead me > back to another entity with signals and different variables, the > signals I can wave, the variables...well, restart the sim again. > > The drawback of signals is that take longer simulation time...wasted > time too. I'm trying to resurrect the test code that I had comparing > use of variables versus signals but I seem to remember about a 10% hit > for signals. But I still use signals because just one blown simulation > that needs to be restarted just to get the variable's history can more > than compensate for that 10%...which for someone picking up somebody > elses code can easily happen since they are not familiar with the code > to begin with to 'know' which variables to wave....in other words > 'supportability'. I try to give the poor shmuck who has to pick up my > code all the help I can...even if it means they're sitting waiting for > an extra 10% ;) > > The variable people have a definite point about simulation time, but > there is really no good data to support the overall debug cycle time > being in any way better using variables. They seem to imply that they > can run 10% more test cases, but it is less than that if they were to > consider the down sides and the probabilities of them occurring (see > above about having to restart...or extra time pondering what they think > the value of the variable is in their head since they can't wave it > without restarting). They still might come out ahead using variables > (and I might too if I did that, one day I might, they do have a point). I also try to avoid variables for another reason (in addition to the ones you stated). Somehow, when variables are used I can't be 100% sure if the resulting code is synthesizable, because it can turn out not to be. Additionally, since I do use signals, variables create the mixup of "update now" and "update later" statements which make the process more difficult to understand. With signals only it's all "update later". > I never use async resets with the exception of the flip flop that > receives the external reset signal that is the start of a shift chain > for developing my internal design reset. Don't you run into fanout problems for that single flip-flop that pushes the sync reset signal to all other FFs in the design, or does the synthesis tool take care of this ? I tend to use async resets, but my whole design is usually synchronized to the same clock so there are no reset problems. > > I never have issues with some clocked signals getting cleared and > others not or going to unexpected states (see above paragraph). I have > however fixed several designs that did use asynchronous resets > inappropriately both on a board and within programmable logic. > > I don't recall ever having to fix reset issues on others designs when > synchronous resets were used...hmm, well maybe I've just lived in a > narrow design world. Can you point out a few common problems with async resets ? In particular, what is using them "appropriately" and what isn't ? EliArticle: 107393
fpga_toys@yahoo.com schrieb: > fpga_toys@yahoo.com wrote: > > and to make sure the documentation > > for these boards is complete, including the compliance failures. > > This is probably the most unethical part of Xilinx, ommissions which > suck you and I into wasting valuable time and resources on a completely > unusable design strategy. > > How do you trust anything, when your supplier has a track record of > omissions ... and failure to disclose problem areas .... from valid > (meets ISE timing reports) designs failing on parts, to lack of SATA > compliance of reference designs?? And then compound that with Austin's > and Peter's overt denial of problems in this forum, till cornered. > > "Lost, Totally" (as Austin ridicules) .... is Xilinx, Austin, and Peter. eeaaasy up! 1) XUP Board is *not* made by Xilinx, neither is Xilinx claiming it can do SATA 2) At the time SEG designed ML300 V2Pro MGT characterization was possible not completed and/or SEG had no information on the actual useability of SATA on V2Pro. So the only thing to be fixed is one line in ML300 documentation, I think most other Xilinx own referencies to V2Pro-SATA have been fixed. One documentation item not being fixed can be 'just overlooked' by someone. 3) ML405 and ML410 also include SATA - on those boards I would assume it should be useable. However it is also remotly possible they got designed when the FX silicon was not tested as the V4FX MGT testing was finished very late. in any case - I can not and do not want to belive that Xilinx designed boards with features knowing not to work (at the time of the board design). AnttiArticle: 107394
Thanks for interestign link. > [1] Is Arbiter pure comb logic? If yes, shall its comb logic delay be > constrained to within one clock cycle? In general no. Only trivial static priority arbiter can be a simple combinational logic. In practice the aribters need to store a prior state (or states) information to modify the priority and this requires sequential logic/memory etc. The priority is made dynamic to achieve some particular goals: for example to prevent starvation of low priority requesters while still give low latency to high priority ones. It all very much depends on application. Network devices have really elaborate arbiter algorithms. > [2] Shall one request and one grant both hold only one clock cycle? Obviously request will be active for several clock cycles. This is beacuse some waiting time for acknowledge is necessary. (If not then why would we need arbiter?) Acknowledge is one clock cycle but this is because there is no beneft in making it any longer. One cycle acknowledge is "atomic" BTW Paper specifies many more advanced schemes where acknowledge is delayed and a pointers are used in requester to figure out how many requests have been acknowledged. Cheers, Przemek Davy wrote: > Hi all, > > I have two problem when reading the paper from > [url]http://www.siliconlogic.com/pdf/Arbiters_MattWeber_SLE.pdf [/url] > > [1] Is Arbiter pure comb logic? If yes, shall its comb logic delay be > constrained to within one clock cycle? > [2] Shall one request and one grant both hold only one clock cycle? > > Best regards, > DavyArticle: 107395
David wrote:
> Hi all,
>
> I'm trying to implement a correlator as a coprocessor on the FSL bus.
> The first thing I've done is generate the FSL example using the create
> peripheral wizard in EDK 8.1 and hooked it up to the MicroBlaze. When
> I do a blocking write or read the MB stalls - my understanding is that
> this will happen if the FSL FIFO is full or empty respectively, but it
> happens the first time I write to it, so the FIFO should not be full.
>
> If I use non-blocking reads and writes and check the error and invalid
> flags after each one using fsl_isinvalid() and fsl_iserror() - see code
> below - everything seems normal but the output is always zero. Am I
> implementing the error checking macros correctly?
>
>
> #define write_into_fsl(val, id) nputfsl(val, id)
> #define read_from_fsl(val, id) ngetfsl(val, id)
>
> #define WRITE_FSL_TEST_0(val) write_into_fsl(val,
> XPAR_FSL_FSL_TEST_0_INPUT_SLOT_ID)
> #define READ_FSL_TEST_0(val) read_from_fsl(val,
> XPAR_FSL_FSL_TEST_0_OUTPUT_SLOT_ID)
>
>
> void fsl_test_app(
> unsigned int* input_0, /* Array size = 2 */
> unsigned int* output_0 /* Array size = 2 */
> )
> {
> int i;
> Xuint8 is_error = 0;
> Xuint8 is_valid = 0;
>
> print("Entering fsl_test_app \r\n");
>
> //Start writing into the FSL bus
> for (i=0; i<2; i++)
> {
>
> WRITE_FSL_TEST_0(input_0[i]);
> fsl_iserror(is_error);
> xil_printf("error post: %d \r\n", is_error);
> fsl_isinvalid(is_valid);
> xil_printf("valid post: %d \r\n", is_valid);
> }
> print("Finished Write \r\n");
>
> is_error = 0;
> is_valid = 0;
>
> //Start reading from the FSL bus
> for (i=0; i<2; i++)
> {
> READ_FSL_TEST_0(output_0[i]);
> fsl_iserror(is_error);
> xil_printf("error post: %d \r\n", is_error);
> fsl_isinvalid(is_valid);
> xil_printf("valid post: %d \r\n", is_valid);
> }
> }
>
> I added external ports to the FSL core to check the reset polarity and
> monitor the state machine - the core is not being held at reset, but
> always sits in the Idle state. This, coupled with the blocking
> instruction problems seems to indicate an issue with the FSL FIFO
> perhaps (I have tried both BRAM and non-BRAM FIFO implementations)?
> If anyone has any ideas on what might be going wrong your help would be
> much appreciated...
>
>
> Cheers,
>
> David
>
Hi,
Can you show the .mhs where you have connected your FSL core with
Microblaze?
Göran Bilski
Article: 107396Antti wrote: > 1) XUP Board is *not* made by Xilinx, neither is Xilinx claiming it can > do SATA 1) title blocks on schematics ... Xilinx authorship/ownership 2) Reference manual ... Xilinx authorship/ownership 3) PCB artwork ... Xilinx authorship/ownership 4) Search RM for Digilent ... reference only compatability with Digilent boards. The unit does have Digilent compatable I/O ports, and may well have been designed under contract for Xilinx, but that does make it a Xilinx labeled Product that they claim ownership of, no matter who is building it for them. In fact, everything suggests it's actually a Xilinx Research Labs design instead ... specifically using Digilent I/O connectors for the University Program, to make it compatable with student board projects. And yes, I did finally find the statement on the bottom of page 67 in the reference manual which starts "the SATA specification requires an out of band signalling state that is to be used when the channel is idle. ... " Which means that since this is REQUIRED, and not provided the serial interfaces are NOT SATA, but simply have the same data rates and encoding ... not SATA which is a full system level specification. Using SATA everywhere to describe the interface, and not meeting the specification is simply bait and switch, substituting the Xilinx bit serial interconnect in it's place which just happens to be a non-compatable subset of the SATA standard. A parallel 16 bit data bus with control signals is not SCSI, unless it at least is capable of operating with the complete SCSI protocol ... anything short of that, and it's SASI, Pertec, or some other 16 bit bus, maybe even 16 bit ISA/EISA.Article: 107397
fpga_t...@yahoo.com schrieb: > Antti wrote: > > 1) XUP Board is *not* made by Xilinx, neither is Xilinx claiming it can > > do SATA > > 1) title blocks on schematics ... Xilinx authorship/ownership > 2) Reference manual ... Xilinx authorship/ownership > 3) PCB artwork ... Xilinx authorship/ownership > 4) Search RM for Digilent ... reference only compatability with > Digilent boards. > > The unit does have Digilent compatable I/O ports, and may well have > been designed under contract for Xilinx, but that does make it a Xilinx > labeled Product that they claim ownership of, no matter who is building > it for them. In fact, everything suggests it's actually a Xilinx > Research Labs design instead ... specifically using Digilent I/O > connectors for the University Program, to make it compatable with > student board projects. > > And yes, I did finally find the statement on the bottom of page 67 in > the reference manual which starts "the SATA specification requires an > out of band signalling state that is to be used when the channel is > idle. ... " > > Which means that since this is REQUIRED, and not provided the serial > interfaces are NOT SATA, but simply have the same data rates and > encoding ... not SATA which is a full system level specification. Using > SATA everywhere to describe the interface, and not meeting the > specification is simply bait and switch, substituting the Xilinx bit > serial interconnect in it's place which just happens to be a > non-compatable subset of the SATA standard. > > A parallel 16 bit data bus with control signals is not SCSI, unless it > at least is capable of operating with the complete SCSI protocol ... > anything short of that, and it's SASI, Pertec, or some other 16 bit > bus, maybe even 16 bit ISA/EISA. my mistake. somewhat I assumed the XUP board is designed by digilent (but digilent uses EAGLE cad tool and XUP board is made with professional CAD tool), or more precisly I assumed it is not designed by SEG. Well whatever it is, the copyright ownership is clearly owned fully by Xilinx so the responsibility is also at Xilinx. the OOB requirement - read my posts again and look again at page 29 of the schematic, the OOB requirement is OK, as the circuitry required for the OOB workaround for V2Pro is available. Means you can use XUP for SATA - the only constraint is that you can not claim full compliance as some drives will fail to be detected. AnttiArticle: 107398
> Martin Schoeberl wrote: >> I've uploaded the first draft of the paper: >> http://www.jopdesign.com/doc/simpcon_date.pdf >> >> It's still very similar to the SimpCon definition >> at opencores.org. Comments are very welcome. >> >> To KJ and Tommy: I've added you both in the >> Acknowledgments. I hope this is ok with you ;-) > > I fail to see what's "controversial" about our discussion. Maybe you meant "heated". in my feeling the discussion with KJ is a little bit 'controversial', but this is meant positiv. However, I can remove this ;-) > > As a reviewer (I used to be academic) I'd be very concerned that you fail to disclose that SimpCon is single-master only, and thus > not a full alternative to the others listed. And that's still our little controverse. I agree that SimpCon is not ideal for several outstanding requests from a single master. However, I don't see an issue for a multi-master system with SimpCon. It's possible with Wishbone and SimpCon is 'more expressive' than Wishbone, right? MartinArticle: 107399
A 390-Ohm series resistor normally works ok. If you look at the starter kits that use Spartan3E you see that all the 5V stuff has this to connect to the FPGA. If you don't fancy that then you can get a dedicated IC, like an LCX125... Beware that they're fairly slow, the resistor is better IMHO. http://www.fairchildsemi.com/ds/74/74LCX125.pdf Good luck. Ben "Leon" <leon.heller@bulldoghome.com> wrote in message news:1156737751.068122.325670@m73g2000cwd.googlegroups.com... > > Nevo wrote: >> "Nevo" <nevo_n@hotmail.com> wrote in message >> news:zwrIg.2012$XD1.1382@trnddc01... >> > Newbie alert... >> > >> > I would like to drive my Spartan 3 design with inputs from a 5V source. >> > I've been unable to find anything in the Spartan 3 datasheet that lets >> > me >> > know if this is do-able. (The signal will be coming fom the parallel >> > port >> > on my laptop, which I suspect probably is 3.3V but I want to be on the >> > safe side.) >> > >> > Any tips are appreciated. >> > >> > Thanks, >> > >> > -Nevo >> >> Hm... I found http://direct.xilinx.com/bvdocs/appnotes/xapp179.pdf, which >> lists the 5V tolerant SelectIO standards for the Spartan 2 family (and >> implicitly says none of the standards are 5V tolerant in the Spartan 2E >> family), but I'm unable to find a simlar reference for the Spartan 3 >> family. >> >> Table 27, Absoulte Maximum Ratings under DC Electrical Characteristics, >> suggests that putting 5V into the chip is a no-no. >> >> Hm; I think I'm going to answer my own question here by pointing myself >> to >> XAPP429 and a whole host of archived messages in comp.arch.fpga. > > You need some sort of interface if you want to use 5V I/O with the > Spartan 3. You have lots of options. > > Leon >
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