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
2019JanFebMar2019

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 129725

Article: 129725
Subject: Re: Xilinx's microblaze hangs when a timer interrupt occurs after a "rand()" instruction.
From: "Göran Bilski" <goran.bilski@xilinx.com>
Date: Tue, 4 Mar 2008 09:02:23 +0100
Links: << >>  << T >>  << A >>
Hi Rémy,

Can you provide me with the MicroBlaze configuration settings (or the whole 
.mhs file)?
It looks like you get a hardware exception but you don't have a exception 
handler.
What hardware exceptions have you enabled on MicroBlaze?

Göran

"Rémy" <thomasrt2008@gmail.com> wrote in message 
news:f6cbd175-5bc5-4a9a-9b64-5e8a1b386299@e6g2000prf.googlegroups.com...
Hi,

I just try the patch http://www.xilinx.com/support/answers/30051.htm
and the bug steal occurs if I have a "rand" or "srand" function in my
code.
When i stop the CPU under XMD it returns me the same adress:
0x820036a4

if i do "mb-objdump -x -D -S -t executable.elf > dump.out" to output a
dump file of my *.elf to see what there is at this address:

.section .text
.align 2
.ent _hw_exception_handler
_hw_exception_handler:
        bri     0;
820036a4: b8000000 bri 0 // 820036a4

so apparently the code is crashed because of an exeption like the
problem in "Answer Record #29784 (http://www.xilinx.com/support/
answers/
29784.htm".  Although i work on the last version of tools with the SP2
and the last patch....

I have tried my code on a PowerPC architecture with the same IP on the
same Hardware and I don't have the bug.

Rémy 



Article: 129726
Subject: Re: verifying UNIFORM using matlab
From: Tricky <Trickyhead@gmail.com>
Date: Tue, 4 Mar 2008 01:26:39 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 3, 9:15 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
> I have written a process to generate random numbers using UNIFORM. I
> was trying to check the results using "rand" in matlab. How do i
> initialise the seed values of both these functions to the same value.
> I see that the random numbers generated by UNIFORM are different
> compared to rand when the seed values are left uninitialised.
> What do I need to change so that I get same output from both programs.
>
> Thanks

Uninitilised positives (the seeds in this case) will take a value of 1
when they are put into the uniform function. Unitialised types when
used will take type'low as their value

positive'low = 1
std_logic'low = 'u'
etc.

so both of your first calls to uniform are seeding it with two 1s.

I dont know how the seeding works in matlab. It may not even use
positives, but the entire integer range. it is common in C to seed the
random number generator with the system time. Does matlab do something
similar? The C random function only has 1 seed, whereas uniform takes
2.

Article: 129727
Subject: Re: Is there any way to disable JTAG for Sptantan3AN
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Tue, 04 Mar 2008 09:47:47 +0000
Links: << >>  << T >>  << A >>
Antti <Antti.Lukats@googlemail.com> writes:

> 3) Lattice ECP2 have non-volatile AES key, making them best candidate
> if design security/theft is of concern, also the design migration from
> Xilinx to Lattice is much much more easier then Xilinx to Actel

If it's non-volatile, is it not "relatively easy" to extract the key
from the chip by invasive methods?  I say "relatively", compared to
the volatile keys in a virtex device - still not a trivial task :-)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

Article: 129728
Subject: Re: clock distribution accross boards
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Tue, 4 Mar 2008 02:28:08 -0800 (PST)
Links: << >>  << T >>  << A >>
That is a simple question:
It is a device to measure the timing of input signals. We have 25ps
resolution now and want to improve on that.
The problem ist that we can only fit 8 inputs on any board. Most
customers need only less than 8 channels, but some
need a lot more. These are important customers, but the volume is
really low, so we would rather use a standard backplane
with our standard boards.

Kolja


On 3 Mrz., 19:43, austin <aus...@xilinx.com> wrote:
> Kolja,
>
> I hate to say it, but why do you wish to architect a system that has
> this requirement?  Why not solve the problem in a way that does not
> require this 50ps phase alignment?  The added FIFO buffering may be well
> worth the pain of precise clock phase control/signal integrity.
>
> My two pennies,
>
> Austin


Article: 129729
Subject: Re: clock distribution accross boards
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Tue, 4 Mar 2008 02:29:58 -0800 (PST)
Links: << >>  << T >>  << A >>
That is OK. We definitely will have jitter cleanup PLLs on the boards.
I am not looking for a passive solution because I want a simple or
cheap solution,
but because I am worried by the temperature dependant delay of the
active components.

Kolja

On 3 Mrz., 22:54, "MM" <mb...@yahoo.com> wrote:
> Kolja,
>
> You could distribute some slow clock and generate your fast clocks on each
> board independently with high quality PLLs but that's not a pure passive
> solution you've asked for...
>
> /Mikhail


Article: 129730
Subject: Re: clock distribution accross boards
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Tue, 4 Mar 2008 02:36:43 -0800 (PST)
Links: << >>  << T >>  << A >>
On 3 Mrz., 18:45, "Symon" <symon_bre...@hotmail.com> wrote:
> 1) What frequency is the clock? The higher the frequency, the more likely
> you are to have problems with reflections from an edge during the next edg=
e.

And otherwise you think I can get a clean  enough edge across 10
stubs?
(or 5 using Peters suggestion).
The setup is rather complex for a simulation.

> 2) What is the rise time of the clock? The faster the rise time, the bigge=
r
> the reflections, in general.
Well, fast risetimes is a way to reduce phase shifts due to variations
in threshold
and supply voltage. So currently I am looking into very fast rise
times.

> 3) What logic standard is the clock?
Free to choose. I am looking at CML and LVDS currently.

> 4) What does the clock drive on the destination cards? FPGAs have relative=
ly
> large pin capacitance which can cause big reflections at fast edge rates.
Good point, I did not think of that. Maybe external clock buffers on
the inputs
could improve on that.

> Your 50ps requirement rules out any tricks with DCMs, they have that much
> phase noise and more already.
Even external zero delay buffers often have something like 200ps skew.

> I like your daisy chain plan. As you are worried about 50ps, this must be
> the safest way to go. You could use something like the SY58011u 1:2 CML
> buffer from Micrel, depending on your operating temperature range. The
> datasheet has a graph of propagation delay versus temperature. From 10C to=

> 80C the delay changes by 10ps more or less linearly. If you can keep the
> temperature range low, this might be ok. Use one output to drive the board=
,
> the other to drive the next board. They also make 1:4 parts, so the first
> board could drive the next 3, the 4th drives 5,6,7 and so on. So you'd hav=
e
> fewer buffers.
That is a great suggestion. I had a look at multiple parts but only
one of those
specified the temperature effect - which was to big. 10ps over 70=B0C is
rather good.
The linear solution has the advantage that it is easy to make all
boards identical.

> Oh, yeah. Simulate it!

*sigh* It's a big task for simulation. But I probably will have to.

Article: 129731
Subject: Re: my Spartan-4 wishlist
From: buchty@atbode100.lrr.in.tum.de (Rainer Buchty)
Date: Tue, 4 Mar 2008 10:38:41 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <xnr6era4pd.fsf@delorie.com>,
 DJ Delorie <dj@delorie.com> writes:
|> 
|> I keep wondering if there's a market for a few "unbalanced" devices,
|> like something with a ton of gates but in a tqfp-64 package.

I bet there is, although probably not a high numbers market -- but anyone
dealing with repairing long-gone legacy devices would love such beasts,
especially when they come with a separate V_I/O input where one could
adjust the logic level to stone-age (5V, 3.3V) -- heck, make at least two 
voltage domains for easy interfacing -- without the need for external drivers 
and level shifters.

And don't forget the internal configuration PROM.

Ok, make that thing reasonably priced and you probably have an ASIC killer
for modest-run "single chip plus some little discrete" stuff, like e.g. the 
C64DTV (IIRC 250.000 units were produced).
 
Rainer (practicing geriatronician)

Article: 129732
Subject: Re: clock distribution accross boards
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Tue, 4 Mar 2008 02:39:11 -0800 (PST)
Links: << >>  << T >>  << A >>
On 3 Mrz., 18:23, John_H <newsgr...@johnhandwork.com> wrote:
> On Mar 3, 8:27 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:
>
>
>
> > Hi,
>
> > maybe you folks can help me with a design decision:
>
> > I need to distribute a clock to up to ten identical boards.
> > The boards are all plugged into a backplane in a single row.
>
> > In addition to the backplane the boards will be connected by
> > a twinax flatband cable on samtec connectors. For the clock
> > distribution I can choose between a bus structure cable or a
> > series of point to point connections between neighbouring boards.
>
> > The leftmost of the identical boards shall provide a clock for all
> > the other boards. I am now concerned that a bus structure with
> > that many stubs will have problems maintaining a good signal quality.
>
> > I could instead use point to point connections with fanout clock
> > buffers on each board to forward the clock to the next board. As far
> > as the signal quality goes this will obviously work very well,
> > BUT the boards need a fixed phase relationship. While the absolute
> > phase is of no importance, the phase must not drift over time or
> > temperature by more than 50ps or so. Ten buffers in a row would
> > probably have a larger drift, wouldn't they?
>
> > Any ideas, how I can make a pure passive distribution work in a setup
> > like that?
>
> > Also: How can I turn on the termination on the last board dynamically?
>
> > Kolja Sulimma
>
> Kolja,
>
> Have you considered using a clock buffer on the backplane?  By using
> point-to-point connections, your design is significantly cleaner but
> you no longer have a passive-only backplane solution.
>
> - John_H

That would work, but than we need custom made backplanes.
An intermediate solution is to have one special board that provides
ten clock lines
and then shifting the clock lines by one on each board. Of course this
clogges 20 lines
on the cable.

Kolja Sulimma


Article: 129733
Subject: Re: Software Defined Radio auf Xilinx Virtex 4
From: jetmarc@hotmail.com
Date: Tue, 4 Mar 2008 02:41:19 -0800 (PST)
Links: << >>  << T >>  << A >>
> Sinus(1Khz)----> ADC-->FPGA--->DAC--->Sinus(1Khz)
> Ich kann schon etwas am Ausgang (nach der DA-Wandler) mit dem
> Kopfh=EF=BF=BDrer
> h=EF=BF=BDren. Allerdings k=EF=BF=BDnnte ich das mit dem Oszilloskop nicht=
 messen .

Vermutlich hast Du einen ganz banalen Fehler in Deinen VHDL Quellen.
Am besten trennst Du die Aufgabe in ihre Bestandteile auf und
betrachtest jeden Teil fuer sich.

Das ADC-Interface kannst Du beispielsweise testen, indem Du die
eingelesenen Daten ueber eine digitale Schnittstelle ausgibst (zB
ueber RS232).  Das DAC Interface in aehnlicher Weise, indem Du Daten
digital eingibst und mit dem Oszi schaust was rauskommt.

Sobald alles fuer sich alleine funktioniert, kannst Du die Teile
zusammenfuegen.

Viel Erfolg,
Marc

Article: 129734
Subject: PARAMETER C_SPLIT error
From: Olaf <is.er@inter.net>
Date: Tue, 04 Mar 2008 12:30:48 +0100
Links: << >>  << T >>  << A >>
Hi,

I'm working with the EDK 9.2 MicroBlaze Tutorial and get the following 
error message:

ERROR:MDT - D:\work\xilinx\HW-SPAR3E-SK-EC-G\MB_Test1\system.mhs line 
245 - PARAMETER C_SPLIT has value 8 which does not fall in the range 
(1:C_SIZE_IN-1), specified in MPD

the (hopefully relevant) section in system.mhs file are:
---8<---
...
BEGIN xps_mch_emc
  PARAMETER INSTANCE = FLASH
  PARAMETER HW_VER = 1.00.a
  PARAMETER C_MCH_PLB_CLK_PERIOD_PS = 10000
  PARAMETER C_NUM_BANKS_MEM = 1
  PARAMETER C_MAX_MEM_WIDTH = 8
  PARAMETER C_MEM0_WIDTH = 8
  PARAMETER C_INCLUDE_DATAWIDTH_MATCHING_0 = 1
  PARAMETER C_SYNCH_MEM_0 = 0
  PARAMETER C_TCEDV_PS_MEM_0 = 110000
  PARAMETER C_TWC_PS_MEM_0 = 110000
  PARAMETER C_TAVDV_PS_MEM_0 = 110000
  PARAMETER C_TWP_PS_MEM_0 = 70000
  PARAMETER C_THZCE_PS_MEM_0 = 35000
  PARAMETER C_TLZWE_PS_MEM_0 = 15000
  PARAMETER C_MEM0_BASEADDR = 0x89000000
  PARAMETER C_MEM0_HIGHADDR = 0x89ffffff
  BUS_INTERFACE SPLB = mb_plb
  PORT Mem_A = fpga_0_FLASH_Mem_A_split
  PORT Mem_DQ = fpga_0_FLASH_Mem_DQ
  PORT Mem_OEN = fpga_0_FLASH_Mem_OEN
  PORT Mem_WEN = fpga_0_FLASH_Mem_WEN
  PORT Mem_CEN = fpga_0_FLASH_Mem_CEN
END
...
BEGIN util_bus_split
  PARAMETER INSTANCE = FLASH_util_bus_split_0
  PARAMETER HW_VER = 1.00.a
  PARAMETER C_SIZE_IN = 32
  PARAMETER C_LEFT_POS = 0
  PARAMETER C_SPLIT = 8			// L245
  PORT Sig = fpga_0_FLASH_Mem_A_split
  PORT Out2 = fpga_0_FLASH_Mem_A
END
...
---8<---
what happens here? The tutorial is designed for Virtex4 / ML403 Board , 
but this should matter imo. I'm using the spartan3e starter kit.

Thanks,
Olaf

Article: 129735
Subject: Re: PARAMETER C_SPLIT error
From: Olaf <is.er@inter.net>
Date: Tue, 04 Mar 2008 12:32:10 +0100
Links: << >>  << T >>  << A >>
> what happens here? The tutorial is designed for Virtex4 / ML403 Board , 
> but this should matter imo. I'm using the spartan3e starter kit.
... should not matter ...

sry.

Article: 129736
Subject: Re: PARAMETER C_SPLIT error
From: Andreas Hofmann <ahnews@gmx.net>
Date: Tue, 04 Mar 2008 13:20:43 +0100
Links: << >>  << T >>  << A >>
Olaf wrote:
> BEGIN util_bus_split
>  PARAMETER INSTANCE = FLASH_util_bus_split_0
>  PARAMETER HW_VER = 1.00.a
>  PARAMETER C_SIZE_IN = 32
>  PARAMETER C_LEFT_POS = 0
>  PARAMETER C_SPLIT = 8            // L245
                                    ^^
This looks like a syntax error. For comments use # and best place it on
a seperate line.

Best regards,
Andreas

Article: 129737
Subject: Re: PARAMETER C_SPLIT error
From: Olaf <is.er@inter.net>
Date: Tue, 04 Mar 2008 14:33:56 +0100
Links: << >>  << T >>  << A >>
Andreas Hofmann schrieb:
> Olaf wrote:
>> BEGIN util_bus_split
>>  PARAMETER INSTANCE = FLASH_util_bus_split_0
>>  PARAMETER HW_VER = 1.00.a
>>  PARAMETER C_SIZE_IN = 32
>>  PARAMETER C_LEFT_POS = 0
>>  PARAMETER C_SPLIT = 8            // L245
>                                     ^^
> This looks like a syntax error. For comments use # and best place it on
> a seperate line.

This was only for this NG to mark the line.

Thanks,
Olaf

Article: 129738
Subject: Re: real to signed
From: FPGA <FPGA.unknown@gmail.com>
Date: Tue, 4 Mar 2008 05:58:11 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 3, 4:08=A0am, Tricky <Trickyh...@gmail.com> wrote:
> On Feb 29, 6:33 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
>
>
>
>
>
> > On Feb 29, 11:29 am, Tricky <Trickyh...@gmail.com> wrote:
>
> > > On Feb 29, 2:46 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
>
> > > > How to convert real to signed. The range of real will be from -1 to =
1,
> > > > -5 to 5, -10 to 10 and so on. I would like to convert this range to =
a
> > > > signed vector of bit width bw(generic). The data has to be scaled bu=
t
> > > > I have no idea on how to do it. I have searched on the internet and
> > > > did not find any valuable information.
>
> > > You will need to know magnitude width and fraction width as you will
> > > be generating a fixed point decimal.
> > > Magnitude width (MW) can be done by taking log2(limit) and adding 1
> > > (to account for the sign bit).
>
> > MW and FW of =A0output real changes with change in amplitude. What is
> > 'limit'?
>
> > > Fraction width (FW) is then bw-MW.
>
> > > Then you scale the result by 2**FW and convert it to an integer (which=

> > > then gives you your signed number).
> > > Remember Integer(my_real) always rounds to nearest. If you dont want
> > > to round to nearest, you have to write a function that rounds to zero,=

> > > otherwise removing the LSBs will always round down. (towards 0 for
> > > +ve, away from 0 for -ve).
>
> You are ignoring what the MW and FW lengths of the real are, because
> it uses neither. For a real, which is floating point, its not
> magnitude and fraction widths, its mantissa and exponent. You are
> specified what YOU want the real to fit in to. You are making a FIXED
> POINT decimal value, so MW and FW never change. for example:
>
> from 3 to -3
>
> you need MW =3D 3 =A0(1 sign bit an 1 other bit)
> FW =3D how ever many you want. each bit represets 2^-n (with n=3D0 to the
> left of the imaginary point)
>
> so 0.75 is represended by: =A0000.1100000 =3D 2^-1 (0.5) + 2^-2 (0.25)
> 1.75 =3D 001.11000000 =A0=3D 2^0 (1) + 2^-1 (0.5) + 2^-2 (0.25)
> -1.75 =3D 110.01111111 (invert all bits and add one to number above)
> etc
> etc
> All values are 2s compliment, and can then be used in any standard
> adder, multiplier etc on firmware. Just make sure you use the correct
> bits of the result:
>
> a 2.6 number x 6.2 number =3D 8.8 result
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 a a . a a a a a a
> =A0 =A0 =A0 b b b b b b . b b
> =3D r r r r r r r r . r r r r r r r r- Hide quoted text -
>
> - Show quoted text -

Thanks a bunch. Your explaination really helped.

Article: 129739
Subject: Re: verifying UNIFORM using matlab
From: FPGA <FPGA.unknown@gmail.com>
Date: Tue, 4 Mar 2008 06:00:37 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 4, 4:26=A0am, Tricky <Trickyh...@gmail.com> wrote:
> On Mar 3, 9:15 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
>
> > I have written a process to generate random numbers using UNIFORM. I
> > was trying to check the results using "rand" in matlab. How do i
> > initialise the seed values of both these functions to the same value.
> > I see that the random numbers generated by UNIFORM are different
> > compared to rand when the seed values are left uninitialised.
> > What do I need to change so that I get same output from both programs.
>
> > Thanks
>
> Uninitilised positives (the seeds in this case) will take a value of 1
> when they are put into the uniform function. Unitialised types when
> used will take type'low as their value
>
> positive'low =3D 1
> std_logic'low =3D 'u'
> etc.
>
> so both of your first calls to uniform are seeding it with two 1s.
>
> I dont know how the seeding works in matlab. It may not even use
> positives, but the entire integer range. it is common in C to seed the
> random number generator with the system time. Does matlab do something
> similar? The C random function only has 1 seed, whereas uniform takes
> 2.

I am not sure how the rand function in MATLAB works. I tried to search
if the code of the function was described anywhere but couldnt find.
I dont know if we can get MATLAB to generate results as UNIFORM does.
As you said, uniform has 2 seeds while rand has 1.
If anyone has an idea on how this can be done, please post your
comment.


Article: 129740
Subject: Re: verifying UNIFORM using matlab
From: Tricky <Trickyhead@gmail.com>
Date: Tue, 4 Mar 2008 06:12:15 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 4, 2:00 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
> On Mar 4, 4:26 am, Tricky <Trickyh...@gmail.com> wrote:
>
>
>
> > On Mar 3, 9:15 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
>
> > > I have written a process to generate random numbers using UNIFORM. I
> > > was trying to check the results using "rand" in matlab. How do i
> > > initialise the seed values of both these functions to the same value.
> > > I see that the random numbers generated by UNIFORM are different
> > > compared to rand when the seed values are left uninitialised.
> > > What do I need to change so that I get same output from both programs.
>
> > > Thanks
>
> > Uninitilised positives (the seeds in this case) will take a value of 1
> > when they are put into the uniform function. Unitialised types when
> > used will take type'low as their value
>
> > positive'low = 1
> > std_logic'low = 'u'
> > etc.
>
> > so both of your first calls to uniform are seeding it with two 1s.
>
> > I dont know how the seeding works in matlab. It may not even use
> > positives, but the entire integer range. it is common in C to seed the
> > random number generator with the system time. Does matlab do something
> > similar? The C random function only has 1 seed, whereas uniform takes
> > 2.
>
> I am not sure how the rand function in MATLAB works. I tried to search
> if the code of the function was described anywhere but couldnt find.
> I dont know if we can get MATLAB to generate results as UNIFORM does.
> As you said, uniform has 2 seeds while rand has 1.
> If anyone has an idea on how this can be done, please post your
> comment.

Why not generate a file containing all the stimulus for the vhdl and
matlab model in one or the other, instead of trying to recreate the
random sequence?

Article: 129741
Subject: Re: verifying UNIFORM using matlab
From: FPGA <FPGA.unknown@gmail.com>
Date: Tue, 4 Mar 2008 07:23:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 4, 9:12=A0am, Tricky <Trickyh...@gmail.com> wrote:
> On Mar 4, 2:00 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
>
>
>
>
>
> > On Mar 4, 4:26 am, Tricky <Trickyh...@gmail.com> wrote:
>
> > > On Mar 3, 9:15 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
>
> > > > I have written a process to generate random numbers using UNIFORM. I=

> > > > was trying to check the results using "rand" in matlab. How do i
> > > > initialise the seed values of both these functions to the same value=
.
> > > > I see that the random numbers generated by UNIFORM are different
> > > > compared to rand when the seed values are left uninitialised.
> > > > What do I need to change so that I get same output from both program=
s.
>
> > > > Thanks
>
> > > Uninitilised positives (the seeds in this case) will take a value of 1=

> > > when they are put into the uniform function. Unitialised types when
> > > used will take type'low as their value
>
> > > positive'low =3D 1
> > > std_logic'low =3D 'u'
> > > etc.
>
> > > so both of your first calls to uniform are seeding it with two 1s.
>
> > > I dont know how the seeding works in matlab. It may not even use
> > > positives, but the entire integer range. it is common in C to seed the=

> > > random number generator with the system time. Does matlab do something=

> > > similar? The C random function only has 1 seed, whereas uniform takes
> > > 2.
>
> > I am not sure how the rand function in MATLAB works. I tried to search
> > if the code of the function was described anywhere but couldnt find.
> > I dont know if we can get MATLAB to generate results as UNIFORM does.
> > As you said, uniform has 2 seeds while rand has 1.
> > If anyone has an idea on how this can be done, please post your
> > comment.
>
> Why not generate a file containing all the stimulus for the vhdl and
> matlab model in one or the other, instead of trying to recreate the
> random sequence?- Hide quoted text -
>
> - Show quoted text -

The goal is to check that the VHDL code generates results similar to
MATLAB . I have written the outputs of both in seperate text files. I
am not able to initialise the rand function to generate results
similar to MATLAB and vice versa. Called MATLAB today to get some more
information on how they have developed the rand function. They said
that this information is not available to the public.
I think one of the ways to do this would be, generating a pdf function
for both cases and showing that their random distriution is similar.

If any of you have other ideas please post them.

Article: 129742
Subject: Re: verifying UNIFORM using matlab
From: Tricky <Trickyhead@gmail.com>
Date: Tue, 4 Mar 2008 07:45:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Mar 4, 3:23 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
> On Mar 4, 9:12 am, Tricky <Trickyh...@gmail.com> wrote:
>
>
>
> > On Mar 4, 2:00 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
>
> > > On Mar 4, 4:26 am, Tricky <Trickyh...@gmail.com> wrote:
>
> > > > On Mar 3, 9:15 pm, FPGA <FPGA.unkn...@gmail.com> wrote:
>
> > > > > I have written a process to generate random numbers using UNIFORM. I
> > > > > was trying to check the results using "rand" in matlab. How do i
> > > > > initialise the seed values of both these functions to the same value.
> > > > > I see that the random numbers generated by UNIFORM are different
> > > > > compared to rand when the seed values are left uninitialised.
> > > > > What do I need to change so that I get same output from both programs.
>
> > > > > Thanks
>
> > > > Uninitilised positives (the seeds in this case) will take a value of 1
> > > > when they are put into the uniform function. Unitialised types when
> > > > used will take type'low as their value
>
> > > > positive'low = 1
> > > > std_logic'low = 'u'
> > > > etc.
>
> > > > so both of your first calls to uniform are seeding it with two 1s.
>
> > > > I dont know how the seeding works in matlab. It may not even use
> > > > positives, but the entire integer range. it is common in C to seed the
> > > > random number generator with the system time. Does matlab do something
> > > > similar? The C random function only has 1 seed, whereas uniform takes
> > > > 2.
>
> > > I am not sure how the rand function in MATLAB works. I tried to search
> > > if the code of the function was described anywhere but couldnt find.
> > > I dont know if we can get MATLAB to generate results as UNIFORM does.
> > > As you said, uniform has 2 seeds while rand has 1.
> > > If anyone has an idea on how this can be done, please post your
> > > comment.
>
> > Why not generate a file containing all the stimulus for the vhdl and
> > matlab model in one or the other, instead of trying to recreate the
> > random sequence?- Hide quoted text -
>
> > - Show quoted text -
>
> The goal is to check that the VHDL code generates results similar to
> MATLAB . I have written the outputs of both in seperate text files. I
> am not able to initialise the rand function to generate results
> similar to MATLAB and vice versa. Called MATLAB today to get some more
> information on how they have developed the rand function. They said
> that this information is not available to the public.
> I think one of the ways to do this would be, generating a pdf function
> for both cases and showing that their random distriution is similar.
>
> If any of you have other ideas please post them.

In that case, why are you even trying to do this? generate a file from
matlab that is used as the stimulus for the VHDL testbench. Then you
do not need to use the uniform function at all, and then you are
testing that the results match.

Article: 129743
Subject: FPGA for a DVB common interface implementation
From: manuel-lozano@mixmail.com
Date: Tue, 4 Mar 2008 07:56:12 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

anybody has any (practical) information about the Common Interface
specification for DVB receivers?

I have some ideas (for example a DVB-CI module that feed the transport
stream from DVB receiver to Ethernet) in order to analyse or broadcast
to other devices in the network

I have the simplest implementation would be an FPGA with an embedded
CPU.

Anybody knows about the Common Interface physical specification
(pins,etc..) ? Any reference design or anything that can help in kick
off the idea?

I have seen "oficial" documentation from ETSI, CENELEC, etc. but it is
too general to start quickly

Thanks,
Manuel

Article: 129744
Subject: FPGA for a DVB common interface implementation
From: manuel-lozano@mixmail.com
Date: Tue, 4 Mar 2008 07:56:24 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,

anybody has any (practical) information about the Common Interface
specification for DVB receivers?

I have some ideas (for example a DVB-CI module that feed the transport
stream from DVB receiver to Ethernet) in order to analyse or broadcast
to other devices in the network

I have the simplest implementation would be an FPGA with an embedded
CPU.

Anybody knows about the Common Interface physical specification
(pins,etc..) ? Any reference design or anything that can help in kick
off the idea?

I have seen "oficial" documentation from ETSI, CENELEC, etc. but it is
too general to start quickly

Thanks,
Manuel

Article: 129745
Subject: Re: my Spartan-4 wishlist
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 4 Mar 2008 08:22:49 -0800 (PST)
Links: << >>  << T >>  << A >>
On 3 Mrz., 23:08, n...@puntnl.niks (Nico Coesel) wrote:
> "M.Randelzhofer" <techsel...@gmx.de> wrote:
> >"Antti" <Antti.Luk...@googlemail.com> schrieb im Newsbeitrag
> >news:467475ec-6d16-4789-acec-07d3c1a4977e@s19g2000prg.googlegroups.com...
> >> here it is:
>
> >> 1) devices densities like in Spartan-3 (50..5000)
> >> 2) devices packages like Spartan-3E (including QN132 !) or better
> >> (microBGA 6x6 mm?)
> >> 3) all good features of S3A/AN !!
> >> 4) design security with OTP encryption key (like Lattice ECP2)
> >> 5) other features as already planned by Xilinx
>
> >> Antti
> >> has made his Christmas wish this year... or did I just describe
> >> Lattice XP3 or Cyclone IV?
> >> eh, I just wish Spartan-4 will have all the good things from Spartan-3
> >> subfamilies+extra goodies.
>
> >Hi Antti,
>
> >I've the same wishes, some additional i/O & memory cores would be nice:
>
> >6) USB2 host/slave interface with integrated PHY
>
> >7) Ethernet MAC + PHY
>
> >8) DDR2/3 core
>
> >9) some analog stuff (ADC, temp sensor, system supervisor)
>
> >S4 would be a serious competitor to 32bit microcontrollers, if some of their
> >standard peripherals are included in low price FPGA's.
>
> You forget a standard ARM core, some internal flash (say 32KB to
> 256KB), some memory (8KB to 64KB) and some standard pheripherals like
> UART, SPI, I2C. Such a device would be a real killer. I would design
> it in straight away if it existed today for a Spartan price.
>
> --
> Programmeren in Almere?
> E-mail naar nico@nctdevpuntnl (punt=.)

well, Xilinx already own ARM IP-Core license, when Xilinx purchased
Triscend
they also got the IP licenses ownded by Triscend what included also
ARM.

so it is possible that the ARM core see new life in Spartan-4,
Xilinx has no extra royalty to pay

Antti










Article: 129746
Subject: [Altera] How to infer some code into ROM-blocks (in automatic way),
From: sdf <drop669@gmail.com>
Date: Tue, 4 Mar 2008 08:24:22 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi.
My qustion is probably dumb. But i'm stuck here.
In my design I have a lot of code that can be inferred into ROM
automatically, and it does.
However, my device doesn't have enough ROM blocks.
My question: is it possible by Quartus to infer some code into ROM
blocks when it is possible and all the rest let him to make synthesis
using ALUTs?
Or should I manually divide all my ROM-like code to what will inferred
into ROM blocks and that part which will be done usign ALUTs?

Article: 129747
Subject: Re: How to infer some code into ROM-blocks (in automatic way), but
From: sdf <drop669@gmail.com>
Date: Tue, 4 Mar 2008 08:29:17 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi.

Oh, I forgot to write: I use Quartus 7.2sp2 and my device is EP2S60.

Article: 129748
Subject: Re: FPGA for a DVB common interface implementation
From: sky465nm@trline5.org
Date: Tue, 4 Mar 2008 17:34:37 +0100 (CET)
Links: << >>  << T >>  << A >>
manuel-lozano@mixmail.com wrote:
>anybody has any (practical) information about the Common Interface
>specification for DVB receivers?

>I have some ideas (for example a DVB-CI module that feed the transport
>stream from DVB receiver to Ethernet) in order to analyse or broadcast
>to other devices in the network

>I have the simplest implementation would be an FPGA with an embedded
>CPU.

>Anybody knows about the Common Interface physical specification
>(pins,etc..) ? Any reference design or anything that can help in kick
>off the idea?

The CI interface is a synchronous interface with frame & byte sync and 8-bit
data. I think it's daisy chained too. It's not that complicated I think. 
Just search on google a bit to find.


Article: 129749
Subject: Re: clock distribution accross boards
From: "MM" <mbmsv@yahoo.com>
Date: Tue, 4 Mar 2008 11:49:42 -0500
Links: << >>  << T >>  << A >>
"Kolja Sulimma" <ksulimma@googlemail.com> wrote in message 
news:9519513d-3ee5-43cd-a73b-ee857094f8f5@e31g2000hse.googlegroups.com...
> That is OK. We definitely will have jitter cleanup PLLs on the boards.

Well, jitter cleanup is not what I am talking about. Take for example 10 MHz 
as your base clock (actually sinewave might be preferable because of better 
phase noise) and generate whatever your want on each of your boards with 
high-precision PLLs. You can even synchronize them all with a bussed signal.

> I am not looking for a passive solution because I want a simple or
> cheap solution,

I don't know how cheap you can make it with requirements in picoseconds...

/Mikhail






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
2019JanFebMar2019

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