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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 94950

Article: 94950
Subject: Re: Raggedstone specifications ...
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Thu, 19 Jan 2006 19:59:40 -0000
Links: << >>  << T >>  << A >>
We have built the capability to drive the JTAG from the FPGA into 
Raggedstone1 in a similar fashion to what we did in MINI-CAN. You need the 
first build containing the PCI and JTAG interfaces to be loaded by the the 
ye olde JTAG cable. After that and providing you keep the PCI/JTAG interface 
in all subsequent builds the hardware features will be there so you can keep 
reprogramming the Platform Flash.  The hard bit is driver/software support 
that may have to change as you add and remove different bits to the overall 
design.

Longer term we may build the JTAG interface into our own PCI core so that is 
there any time our core is used but it certainly will not be in the first 
cut of that core. It is our intention to have some kind of GUI interface but 
the details and practicality of this are awaiting some man time to do it.

Our PCI core will be available in a "lite" version to owners of Raggedstone1 
free for use with their board. If you want to take the core onto a board 
design of your own, or have the more advance version,  there will be a 
license fee based on a tier of usage. We will try to make this reasonable 
for the smaller guys out there so that the entry cost isn't a barrier to a 
small volume/value commercial project.

John Adair
Enterpoint Ltd. - Home of MINI-CAN. The Spartan-3 CAN Bus Development Board.
http://www.enterpoint.co.uk


"Phil Tomson" <ptkwt@aracnet.com> wrote in message 
news:dqnd2611rjo@enews1.newsguy.com...
> In article <1137574950.42552.0@demeter.uk.clara.net>,
> John Adair <removethisthenleavejea@replacewithcompanyname.co.uk> wrote:
>>Phil
>>
>>What you need as a driver depends on your software. I'm not a softy so I 
>>am
>>not best person to talk about this. If you simply want to use a PC slot to
>>power the card or do what Antti has done with his design that turns a RS1
>>into a parallel port look-alike you can get away without supplying a 
>>driver.
>
> I don't need to be able to program the part on the board through PCI (I 
> could
> program it through the parallel cable), but after the part is programmed I
> want to be able to transfer data between the CPU and the FPGA over the PCI
> bus.
>
> If I understand correctly, I only need the driver if I want to be able to
> program the FPGA through the PCI - is that a correct assumption?
>
>>
>>We are getting a drivers, XP and Linux, for our own PCI core but probably
>>4-8 weeks away from releasing the first of these. We have a number of
>>customers using Linux on various boards so if you ask in the Linux 
>>community
>>newsgroups someone may offer a driver.
>
> Sounds good (if I could program the FPGA through the PCI bus, that would 
> be
> great, but it's not absolutely needed I think).  Is your PCI core freely
> available with the board?
>
> Phil 



Article: 94951
Subject: Re: Data2Mem with CRC for Virtex FPGAs
From: "Antti Lukats" <antti@openchip.org>
Date: Thu, 19 Jan 2006 21:20:50 +0100
Links: << >>  << T >>  << A >>
"John D. Davis" <johnd@stanford.edu> schrieb im Newsbeitrag 
news:Pine.GSO.4.44.0601181400370.9227-100000@elaine15.Stanford.EDU...
> Is your library for the CRC generation available to others.
>
> JOhn
>

hi John

I just sent per email to you an updated version (tested with Virtex) of 
bit2frames application
that is based on our bitsream library, if you can verify that the tool works 
and is able to process
and properly calculate the CRC in your bitstreams then well we can give the 
source out too,

ah one more adivce make sure not to use compression whrn working with 
data2mem, but
I guess you are not using it anyway.

the bit2frames I just sent is also not tested with compressed Virtex 
bitsreams yet

Antti 



Article: 94952
Subject: Re: Raggedstone specifications ...
From: "Xavier T" <xavier.tastet@gmail.com>
Date: 19 Jan 2006 12:24:03 -0800
Links: << >>  << T >>  << A >>
with the core you're working on, how many space left to implement
design ?  x3s400 means 400k gates ? 
X.


Article: 94953
Subject: Xilinx padding LC numbers, how do you feel about it?
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 19 Jan 2006 12:35:11 -0800
Links: << >>  << T >>  << A >>
As we have all known for some time, Xilinx has had a habit of padding
the logic cell counts in their data sheets to account for
"effectiveness".  This factor is 1.125 or 9 LCs per CLB in the newest
parts.  I still find this very odd, but mainly annoying because when I
want the true LC count, I have to calculate it myself.

Anyone else find this to be a bit rediculous?


Article: 94954
Subject: Re: Xilinx padding LC numbers, how do you feel about it?
From: "John_H" <johnhandwork@mail.com>
Date: Thu, 19 Jan 2006 20:55:05 GMT
Links: << >>  << T >>  << A >>
Of course it's ridiculous!

Marketing loves to make engineers hate the company.  They want to make the 
*managers* look past their feeble engineers for approving brand X versus 
brand A (forgetting, of course, that most engineers have the lattitude to 
push for one brand due to the *engineering* tradeoffs).

There are times when you need to shoot the engineer to ship the product 
(just one more tweak is *not* okay!) but thankfully the engineers get to be 
pissed off at marketing until they skew the preference toward the "other" 
brand's mismarketing BS.

Ah, what a wonderful world.  What would it be like, after all, if we have to 
pull our hair out with our CAD tools (PC, synth, P&R, sim) but didn't have 
to get the least bit upset about choosing the part in the first place?

- John_H


"rickman" <spamgoeshere4@yahoo.com> wrote in message 
news:1137702911.352529.98730@g47g2000cwa.googlegroups.com...
> As we have all known for some time, Xilinx has had a habit of padding
> the logic cell counts in their data sheets to account for
> "effectiveness".  This factor is 1.125 or 9 LCs per CLB in the newest
> parts.  I still find this very odd, but mainly annoying because when I
> want the true LC count, I have to calculate it myself.
>
> Anyone else find this to be a bit ridiculous?
> 



Article: 94955
Subject: Re: Xilinx padding LC numbers, how do you feel about it?
From: "Peter Alfke" <peter@xilinx.com>
Date: 19 Jan 2006 13:03:40 -0800
Links: << >>  << T >>  << A >>
Rickman, why do you ask?
Everybody in this newsgroup hates that method, but Xilinx Marketing
thinks that it is a more meaningful metric when comparing different
manufacturer's devices. And it is, like it or not.

This reminds me of the way horsepower was measured for automobiles:
Disconnect the gearbox, the generator, the waterpump, the
airconditioner  and everything else that might drain power.
A red-blooded engineer would say: give me the horsepower where the tire
meets the road....
Peter


Article: 94956
Subject: Re: Xilinx padding LC numbers, how do you feel about it?
From: "Peter Alfke" <peter@xilinx.com>
Date: 19 Jan 2006 13:03:40 -0800
Links: << >>  << T >>  << A >>
Rickman, why do you ask?
Everybody in this newsgroup hates that method, but Xilinx Marketing
thinks that it is a more meaningful metric when comparing different
manufacturer's devices. And it is, like it or not.

This reminds me of the way horsepower was measured for automobiles:
Disconnect the gearbox, the generator, the waterpump, the
airconditioner  and everything else that might drain power.
A red-blooded engineer would say: give me the horsepower where the tire
meets the road....
Peter


Article: 94957
Subject: Re: clock generation with DOPPLER shift
From: Benjamin Marpe <Benjamin.Marpe@rwth-aachen.de>
Date: Thu, 19 Jan 2006 22:24:29 +0100
Links: << >>  << T >>  << A >>
Great,

thanks a lot for all your answers !

I'll try to downmix the analogue VCXO signal...

Bye, BEN


Ulrich Bangert wrote:
> Ben,
> 
> if you can afford to use a small amount of analogue circuitry around your
> fpga, i suggest you use a second 1000010.0 Hz oscillator (this can be a
> "detuned" 1 MHz oscillator) and mix the received signal with this this
> oscillator down to the audio domain using a double balanced mixer. A lowpass
> filter (or better a so called diplexer) must be used at the IF port of the
> mixer.
> 
> The frequency variation in the downmixed signal stays the same, so with this
> arrangement you have shifted the scenario from 1 MHz, where a 5 Hz variation
> is a difficult to detect 5*10E-6 effect to a 10 Hz audio signal where 5 Hz
> variation is a easy to detect 50 % effect. This scheme is the usual one for
> comparing ultra stable oscillators against each other, where variations
> smaller by some orders of magnitude have to be measured.
> 
> No matter what scheme you will use: Keep in mind that a "normal" x-tal
> oscillator has a tempco of app. 1*10E-6/K. So a normal x-tal oscillator will
> give you a 1  Hz variation per Kelvin @ 1MHz, well in the region of the
> Doppler that you want to measure. This is a indication that a "better"
> oscillator has to be used. Don't go for a TCXO, look out for a cheap OCXO.
> 
> Rgegards
> 
> Ulrich Bangert
> 
> "Ben Marpe" <Ben.Marpe@gmx.de> schrieb im Newsbeitrag
> news:1137597178.426492.225110@z14g2000cwz.googlegroups.com...
> 
>>Dear experts in this newsgroup,
>>
>>in my diploma thesis i'm using a FPGA for baseband signal generation.
>>I'm interested in generating and varying a clock of 1Mhz which is
>>DOPPLER shifted +/- 5Hz due to movements between receiver and
>>transmitter.
>>
>>The +/- 5Hz Doppler must be applied in a very "smooth" way, the step
>>resolution should be as fine as possible.
>>
>>Any ideas how to do this on a (Xilinx) FPGA ?
>>The sine output of Xilinx LogiCore DDS isn't necessary and the step
>>resolution might be even a little bit finer for my application.
>>
>>Thanks a lot for every single hint you can give to me !
>>
>>Greetings, BEN
>>
> 
> 
> 

Article: 94958
Subject: Re: How much do you trust your CAD Program?
From: Sylvain Munaut <com.246tNt@tnt>
Date: Thu, 19 Jan 2006 22:40:10 +0100
Links: << >>  << T >>  << A >>
Leon wrote:
> Incorrect footprints can also be very annoying, that has caught me out
> once or twice.
> 
> Leon
> 

I remember once creating a part my self, then discover after I get the
PCB that I didn't unzoom the PDF enough ... i missed the fine print at
the bottom that said "bottom view" ...


	Sylvain

Article: 94959
Subject: Re: Xilinx padding LC numbers, how do you feel about it?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 20 Jan 2006 10:53:31 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Rickman, why do you ask?
> Everybody in this newsgroup hates that method, but Xilinx Marketing
> thinks that it is a more meaningful metric when comparing different
> manufacturer's devices. And it is, like it or not.

How about you try and introduce the meaning of UNITS to them ?

ie let them use LCeq for the marketing DOCS, and also have an absolute,
physical count, of LC = X * Y on the die.

As a radical idea, they could even publish the formula
LCeq = LCactual * MarketingsIdeaOfLevelPlayingFieldFactor


That way, everyone is happy :)

The problems occur when one dept trys to use a std unit,
but hijack it to mean something else. In the end no one knows
where they are.... and everyone is annoyed.

-jg


Article: 94960
Subject: Re: DDR Memory Access Interfact by Virtex-4 FX12
From: "agou" <agou.win@gmail.com>
Date: 19 Jan 2006 14:01:59 -0800
Links: << >>  << T >>  << A >>
Thank you for your suggestions.


Article: 94961
Subject: Re: Xilinx padding LC numbers, how do you feel about it?
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 19 Jan 2006 14:03:59 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Rickman, why do you ask?\

I asked because I wanted to hear the the opinion of others.  I read a
recent Spartan 3 data sheet and noticed that there is now a footnote
explaining they they are padding the number.  I just find this pretty
absurd.  You compared it to car makers measuring horsepower, but that
is a measurement that has parameters.  Countings LCs is counting and
adding a 12.5% fudge factor is marketing, not measurement.  It would be
more like a car maker saying his engines are 9 equivalent cylinders!

But mainly it is frustrating to always have to calculate the correct
number myself.  At least marketing has not gotten to my calculator yet.
 :)


> Everybody in this newsgroup hates that method, but Xilinx Marketing
> thinks that it is a more meaningful metric when comparing different
> manufacturer's devices. And it is, like it or not.

That is silly for you to state this as a fact when it is just your
opinion.  Have you ever had a customer ask you to adjust your LC counts
so they can compare them to the competition?  Who says it is "a more
meaningful metric"?  Your marketing, that's who!

It is one thing to accept that your company lets marketing inflate the
numbers, but please don't insult me by trying to justify it.

Am I alone in regard to finding this annoying?


Article: 94962
Subject: Re: Xilinx padding LC numbers, how do you feel about it?
From: fpga_toys@yahoo.com
Date: 19 Jan 2006 14:05:55 -0800
Links: << >>  << T >>  << A >>

Peter Alfke wrote:
> Rickman, why do you ask?
> Everybody in this newsgroup hates that method, but Xilinx Marketing
> thinks that it is a more meaningful metric when comparing different
> manufacturer's devices. And it is, like it or not.

Actually Pete I don't think it is. It's a very arbitrary number where
apples,
dead tires, horse shit, and tree stumps are all given numerical values
which
have absolutely no relation to particular customers needs, and declared
equal
in decsion tree wieghting in ways certain customers would never do the
wieghting.

If the company would then derate the part for being unable route a
fully used
device, or power a fully used device, or cool a fully used device there
might,
maybe, in a long shot be a justification for the bloat factor.

The reality is that certain applications do not do arrithmentics, do
not need much
if any carry chain, or multipliers, or even very many F5/F6 muxes, but
do need a
lot of LUT's.

Being clear up front that you are offering 2 cases of applies, 4 dead
tires, no horse
shit, and one stump to sit on while eating your apples is a whole lot
clearing than
tring to figure out just how much shit you get for 37.

Old School math ...
John


Article: 94963
Subject: V4 not packing registers into IOBs
From: Peter <peter@vpixx.com>
Date: Thu, 19 Jan 2006 18:02:41 -0500
Links: << >>  << T >>  << A >>

Hello Group,

I'm having difficulty convincing Xilinx ISE (8.1SP1 WebPack) PAR to pack 
some of my signals into the IOBs of an XC4LVX25-FF668.  A simple 
demonstration case is the MIG 1.4 dimm72 VHDL design for the ML461 
memory eval board.  The FPGA editor shows that most of the DDR command 
bus outputs correctly push their registers into the IOBs; however the 
DDR_CS and DDR_ODT output get registered within the fabric.  The 
resulting skew between DDR_CS and the rest of the command bus outputs 
becomes fatal when generating cores for DDR systems with multiple ranks 
(chip-selects).  The skew of 2ns or so is clearly visible in timing 
simulations, and my DDR2 model throws a tantrum about invalid setup time 
on DDR_CS.

I have tried seducing ISE into pushing the DDR_CS registers to the IOBs 
by setting XST "Pack I/O Registers into IOBs" to both "Auto" and "Yes". 
  I have set XST register balancing to "No" and to "Yes" with Move 
First/Last Flip-Flop Stage disabled.  I am also enabling the MAP option 
to Pack I/O Registers/Latches into IOBs.  I am new to Xilinx FPGAs. 
With Altera I would enable Fast Inputs/Outputs in Quartus, and all the 
registered I/O would get pushed to the pads.  Am I missing something 
obvious?

One thing I did notice: DDR_CS (and ODT) is different from the rest of 
the command bus in that it is directly fed a combinatorial term, whereas 
the rest of the command outputs are just relatches of signals registered 
  on previous clocks.  Should this make a difference?  It seems to me 
that a combinatorial term could be routed from a slice to an I/O 
register, just as easily as a registered signal could...

Any thoughts or meditations are appreciated,

	-Peter




Article: 94964
Subject: Bogus Hold Violations with 2X clock on Xilinx ISE 7.1
From: mail@deeptrace.com
Date: 19 Jan 2006 15:27:03 -0800
Links: << >>  << T >>  << A >>
I have a DCM that drives a 1X clock and 2X clock on BUFGs.  In one
case, the enable to a CLK2X register depends on a CLK1X based FF.
Looking at the path delays, there is no problem with setup and hold,
but the timing analyzer reports a hold violation that is essentially
the actual path delay plus the CLK2X period.  The required hold time is
0ns.  Is there any way around this, or should I just ignore the error?
I don't think that it should be showing a half cycle of skew between
two non-phase-shifted clocks.  For some reason, the 2X versus 1X seems
to be confusing it.

Chris


Article: 94965
Subject: Re: Spartan3 initialization with DSP
From: "Leon" <leon_heller@hotmail.com>
Date: 19 Jan 2006 15:42:53 -0800
Links: << >>  << T >>  << A >>

Marco wrote:
> Leon, sorry, could you explain me more in detail what you've done?
> Thanks

'Bit-banging' is slang for clocking out the data by manipulating pins
with software, instead of using hardware, which is how it is done in
the SPORTs. It's often used for asynchronous comms (a software UART),
and for synchronous protocols like SPI, and FPGA configuration.

It was a long time ago, and t've got the software somewhere. It was
quite straightforward, using the Altera documentation.

Leon


Article: 94966
Subject: Quadrature Encoder ::
From: narashimanc@gmail.com
Date: 19 Jan 2006 16:00:11 -0800
Links: << >>  << T >>  << A >>
Hi all, Hope everything is fine on your side.

Key Words: ML300 board, VHDL, XST, XPS, Xilinx

I have written a  VHDL program(look post script)to count pulses from
quadrature encoder. Basically i read both the clocks(here QEP0 and
QEP1) and count on two different conditions based on if the motor is
going forward or backward. In the previous case  count is increased and
the latter case the count is decreased. I store the count in a S/W
accessible slave register generated when i use "Create Peripheral
wizard" (EDK) (slv_reg0)

Usually everything works fine, however at times (roughly 1 out of
15-20) what happens is that when i keep reading from that register
continously(for (i=0;i<100;i++){read from the slave register and
display it} ), previous value to the current value difference is
tremendously huge (say 1234,1235,1236...1278,10378,10379...) something
like that. there is no much change in the hardware(i mean no sudden
surge in Motor rotation/ encoder). I read from the register slv_reg0
using a C program.

{
long temp;
long *my_pointer = (long*) XPAR_abcef_BASEADDR;
temp = *my_pointer;
return temp;

}

I would like to know if i read and write to the register(slv_reg0) at
the same time will there be any problems like this? or what is that
wrong i am doing in this program. I am trying to implement a encoder IP
which coul do this job for me. any help in this regard will be greatly
appreciated.

With Warm Regards,
Chakra.

PS: the VHDL program


--------------------------------------------------------------------------------
--------------new encoder counter algorithm dec
19------------------------------
--------------------------------------------------------------------------------
---Please note that QEP0 and QEP1 are input signals defined in the
ports and are connected
--to GPIO ports. the encoder output from the motor is connected to the
GPIO pins.
--thus everytime there is a pulse in the encoder the GPIO senses it and
thus this IP will be
---able to sense it and count how many pulses the mototr is gone
forward or backward.


process(QEP0, rst)

begin


if (QEP0'event and QEP0= '1') then

if(QEP1 = '0') then

D <= '0';

else
D <= '1';

end if;
end if;



end process;

process(QEP1, rst)

begin



if (QEP1'event and QEP1= '1') then

if(QEP0 = '0') then

E <= '0';

else

E <= '1';

end if;
end if;



end process;

process (QEP0, rst)

begin

if (QEP0'event and QEP0 ='1') then

if ((D='1' and E='0')) then

count1 <= count1 + 1; --motor going forward

elsif(D='0' and E='1') then

count1 <= count1 - 1; --motor going backward

else

count1 <= count1; --do nothing

end if;

end if;

end process;


slv_reg0 <= count1;


Article: 94967
Subject: Re: data2bram and coregen
From: Shalin Sheth <shalin.sheth@xilinx.com>
Date: Thu, 19 Jan 2006 16:57:05 -0800
Links: << >>  << T >>  << A >>
Paul,

You are correct that is the proper use model through NGDbuild.  If you 
are using Project Navigator then you can add the *.BMM and *.ELF file to 
the top level file in your project and it should feed it to NGDBUILD. 
BITGEN will automatically call Data2MEM to initialize the memory. 
BITGEN will also output a *_bd.bmm file that can be used with Data2MEM 
standalone to update the memory with the LOC constraints.

Unfortunately, I have not seen any good way to find the hierarchy name 
for the Block RAM to be place in the BMM file.  I normally run the 
project through one and try to find them in FPGA Editor.  But the XDL 
flows also works.

Cheers,
Shalin-

Paul Hartke wrote:
> As far as I can tell, the model is that a bmm file without placement
> info is fed to ngdbuild with the -bm option.  Each BRAM is associated
> with a hierarchical name and its location in the memory address space. 
> That info is passed through the design flow until bitgen.  Bitgen
> recognizes this info in the design database and creates a new *_bd.bmm
> file which includes the hierarchical names and the physical location
> information.  data2mem uses the memory address space info and the
> physical location information to insert the elf/mem into the fpga
> bitstream.  
> 
> EDK generates the original bmm; currently coregen does not and its not
> clear what the BRAM hierarchical names are in the internal database. 
> There is no need to manually look into floorplanner and/or ucf LOCs to
> use data2mem if you can figure out what the BRAM hierarchical names
> are.  Since coregen doesn't automatically export a bmm with its internal
> hierarchical names, the floorplanner *.fnf file can be used to determine
> them.  Doing it this way allows the placement to change and the backend
> flow keeps working once you know exactly what coregen memories are
> needed.  
> 
> Paul
> 
> Antti Lukats wrote:
> 
>>data2bram seems to work properly only when used by the EDK.
>>
>>the BMM file that it requires *must* have LOC info
>>
>>on possibility is to LOC the BRAMs in the UCF and then inject the
>>same LOC info into BMM manually, doable but hassle
>>
>>the BMM issue has been a problem all the time, maybe its better
>>in 8.1 havent checked but so far it really hasnt be any joy when
>>attempting to use it
>>
>>Antti

-- 
------------------------------
Shalin Sheth
Embedded Applications Engineer
General Products Division
Spartan-3 Generation FPGAs
http://www.xilinx.com/spartan3
http://www.xilinx.com/spartan3e
------------------------------

Article: 94968
Subject: Strange Q1 Output on Xilinx V-4 ISERDES
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Thu, 19 Jan 2006 18:04:30 -0800
Links: << >>  << T >>  << A >>
Dear group,

I have a work around for this issue but it seems a
little strange that the Q1 from the Master ISERDES
is acting a little flaky.  It appears that it copies Q2
from time to time.  The rest of the bits seem fine.

Perhaps this is how I assigned the same signal to
both CLK and OCLK and perhaps one should
be delayed from the other?

Or perhaps this is an artifact of using 7x frequency
and I am the only one on this planet who is using 7x?

Or perhaps its an artifact of using the all the output
bits, including Q5 and Q6 from the slave,
and not just the 7 suggested by Xilinx ?

Brad Smallridge
Ai Vision


cam2_x0_ibufd_inst : IBUFDS
 port map (
   O  => cam2_x0,
   I  => cam2_in(1),
   IB => cam2_in(0) );

   x0_iserdes_master : ISERDES
   generic map (
      BITSLIP_ENABLE => FALSE,   -- TRUE FALSE
      DATA_RATE      => "SDR",   -- DDR SDR
      DATA_WIDTH     =>  6,      -- DDR 4,6,8,10  SDR 2,3,4,5,6,7,8
      INIT_Q1        => '0',
      INIT_Q2        => '0',
      INIT_Q3        => '0',
      INIT_Q4        => '0',
      INTERFACE_TYPE => "MEMORY",  -- model - "MEMORY" or "NETWORKING"
      IOBDELAY       => "IFD",     -- delay chain "NONE","IBUF","IFD","BOTH"
      IOBDELAY_TYPE  => "VARIABLE",-- tap delay "DEFAULT", 
"FIXED","VARIABLE"
      IOBDELAY_VALUE =>  15,      -- initial tap delay 0 to 63
      NUM_CE         =>  1,        -- clock enables 1,2
      SERDES_MODE    => "MASTER",  -- "MASTER" or "SLAVE"
      SRVAL_Q1       => '0',
      SRVAL_Q2       => '0',
      SRVAL_Q3       => '0',
      SRVAL_Q4       => '0')
   port map (
      O         => open,
      Q1        => cam2_x0_bit(0),
      Q2        => cam2_x0_bit(1),
      Q3        => cam2_x0_bit(2),
      Q4        => cam2_x0_bit(3),
      Q5        => cam2_x0_bit(4),
      Q6        => cam2_x0_bit(5),
      SHIFTOUT1 => cam2_x0_shift1,
      SHIFTOUT2 => cam2_x0_shift2,
      BITSLIP   => '0',
      CE1       => '1',
      CE2       => '1',
      CLK       => cam2_clk7x,
      CLKDIV    => cam2_xclk,
      D         => cam2_x0,
      DLYCE     => cam2_dlyce,
      DLYINC    => cam2_dlyinc,
      DLYRST    => cam2_dlyrst,
      OCLK      => cam2_clk7x,
      REV       => '0',
      SHIFTIN1  => '0',
      SHIFTIN2  => '0',
      SR        => cam2_reset );

   x0_iserdes_slave : ISERDES
   generic map (
      BITSLIP_ENABLE => FALSE,   -- TRUE FALSE
      DATA_RATE      => "SDR",   -- "DDR" "SDR"
      DATA_WIDTH     =>  6,      -- DDR 4,6,8,10  SDR 2,3,4,5,6,7,8
      INIT_Q1        => '0',
      INIT_Q2        => '0',
      INIT_Q3        => '0',
      INIT_Q4        => '0',
      INTERFACE_TYPE => "MEMORY",  -- model - "MEMORY" or "NETWORKING"
      IOBDELAY       => "IFD",     -- delay chain "NONE","IBUF","IFD","BOTH"
      IOBDELAY_TYPE  => "VARIABLE",-- tap delay "DEFAULT", 
"FIXED","VARIABLE"
      IOBDELAY_VALUE =>  15,       -- initial tap delay 0 to 63
      NUM_CE         =>  1,        -- clock enables 1,2
      SERDES_MODE    => "SLAVE",   -- "MASTER" or "SLAVE"
      SRVAL_Q1       => '0',
      SRVAL_Q2       => '0',
      SRVAL_Q3       => '0',
      SRVAL_Q4       => '0')
   port map (
      O         => open,
      Q1        => open,
      Q2        => open,
      Q3        => cam2_x0_bit(6),
      Q4        => cam2_x0_bit(7),
      Q5        => cam2_x0_bit(8),
      Q6        => cam2_x0_bit(9),
      SHIFTOUT1 => open,
      SHIFTOUT2 => open,
      BITSLIP   => '0',
      CE1       => '1',
      CE2       => '1',
      CLK       => cam2_clk7x,
      CLKDIV    => cam2_xclk,
      D         => '0',
      DLYCE     => cam2_dlyce,
      DLYINC    => cam2_dlyinc,
      DLYRST    => cam2_dlyrst,
      OCLK      => cam2_clk7x,
      REV       => '0',
      SHIFTIN1  => cam2_x0_shift1,
      SHIFTIN2  => cam2_x0_shift2,
      SR        => cam2_reset );

 



Article: 94969
Subject: Xilinx DDR SDRAM for ML40x
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Thu, 19 Jan 2006 18:23:50 -0800
Links: << >>  << T >>  << A >>
Has anybody ported the
Xilinx DDR SDRAM examples
over to the ML40x boards? 



Article: 94970
Subject: Constellation symbol to bit's soft-probability?
From: "Davy" <zhushenli@gmail.com>
Date: 19 Jan 2006 19:14:31 -0800
Links: << >>  << T >>  << A >>
Hi all,

I am new to demodulation and FEC.

How can I get each bit's soft-probability from the constellation?
For example, the modulation method is 16QAM, How can I get
P(bit1=0),P(bit2=0),P(bit3=0),P(bit4=0)  from a symbol?

Is it belong to the subject of detection and need viterbi algorithm?

Or can you recommend some key words of this subject?

Best regards,
Davy


Article: 94971
Subject: OT:Shooting Ourselves in the Foot
From: "HoustonEngineer" <xxx@yyy.com>
Date: Fri, 20 Jan 2006 03:43:58 GMT
Links: << >>  << T >>  << A >>
Here is an observation - what do y'all think ?

1 - Indian / Chinese / East European /etc people are at least as smart and 
hardworking as Westerner's / Japanese
2 - However, they work for something like $10% of what we will (or could 
live on)
3 - Our major advantage (in terms of these newsgroups) is our experience 
with these subjects/technologies/methods/products
4 - On these newsgroups, many of the questions originate from people in 
India, China or Eastern Europe and are answered by Westerners
5 - Are we shooting ourselves in the foot ?

I'm not suggesting this is a bad thing - after five years in the US I am 
actively looking for opportunities elsewhere - I just thought it was an 
interesting question.

G 



Article: 94972
Subject: Re: OT:Shooting Ourselves in the Foot
From: "larwe" <zwsdotcom@gmail.com>
Date: 19 Jan 2006 20:20:57 -0800
Links: << >>  << T >>  << A >>

> 4 - On these newsgroups, many of the questions originate from people in
> India, China or Eastern Europe and are answered by Westerners
> 5 - Are we shooting ourselves in the foot ?

The good ones will improve themselves anyway.

The bad ones will never be any good.

Knowledge should never be hoarded. Experience cannot be given away,
only /experiences/.


Article: 94973
Subject: Re: OT:Shooting Ourselves in the Foot
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Thu, 19 Jan 2006 20:53:43 -0800
Links: << >>  << T >>  << A >>
On Fri, 20 Jan 2006 03:43:58 GMT, "HoustonEngineer" <xxx@yyy.com>
wrote:

>Here is an observation - what do y'all think ?
>
>1 - Indian / Chinese / East European /etc people are at least as smart and 
>hardworking as Westerner's / Japanese
>2 - However, they work for something like $10% of what we will (or could 
>live on)
>3 - Our major advantage (in terms of these newsgroups) is our experience 
>with these subjects/technologies/methods/products
>4 - On these newsgroups, many of the questions originate from people in 
>India, China or Eastern Europe and are answered by Westerners
>5 - Are we shooting ourselves in the foot ?
>
>I'm not suggesting this is a bad thing - after five years in the US I am 
>actively looking for opportunities elsewhere - I just thought it was an 
>interesting question.
>
>G 
>

Back in my high school days it was common for students to help each
other out; if a classmate didn't understand something, I was happy to
explain it, and I found that others were glad to return the favor.

When I went to college, I realized that I was competing with people
who were very, very smart, and it made me wonder whether I was doing
myself harm by sharing knowledge with others.  I gave this a lot of
thought early in my freshman year, and finally came to the conclusion
that if the only way I could successfully navigate college was to
withold information from others, I'd rather sell shoes.

It's been about 35 years since I made that decision, and I've never
regretted it--in school, on the job, or on Usenet.

Of course, I still draw the line at designing other people's traffic
light controllers. 

Bob Perlman
Cambrian Design Works

Article: 94974
Subject: Re: OT:Shooting Ourselves in the Foot
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 19 Jan 2006 21:01:08 -0800
Links: << >>  << T >>  << A >>
On Fri, 20 Jan 2006 03:43:58 GMT, "HoustonEngineer" <xxx@yyy.com>
wrote:

>Here is an observation - what do y'all think ?
>
>1 - Indian / Chinese / East European /etc people are at least as smart and 
>hardworking as Westerner's / Japanese
>2 - However, they work for something like $10% of what we will (or could 
>live on)
>3 - Our major advantage (in terms of these newsgroups) is our experience 
>with these subjects/technologies/methods/products
>4 - On these newsgroups, many of the questions originate from people in 
>India, China or Eastern Europe and are answered by Westerners
>5 - Are we shooting ourselves in the foot ?
>
>I'm not suggesting this is a bad thing - after five years in the US I am 
>actively looking for opportunities elsewhere - I just thought it was an 
>interesting question.


Is it our destiny to be rich and well fed, while the rest of the world
stays poor and hungry? Must we always be the elite? Is the world
economy a zero-sum game, where we want 90% of the winnings?

John





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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search