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 133975

Article: 133975
Subject: Re: Additional Hardware Module with Xilinx MicroBlaze Processor
From: "Göran Bilski" <goran.bilski@xilinx.com>
Date: Mon, 21 Jul 2008 08:36:54 +0200
Links: << >>  << T >>  << A >>
Hi,

Depending a little on how your busy signals work, you might just hook up 
your module to the FSL interface on MicroBlaze.
Your busy signal needs be high when it can't accept a new word even when 
there is no attempt to write to the module.
MicroBlaze will also just do one cycle write so your module needs to accept 
a new word in one clock cycle when busy is low.

Connect:
din(7 downto 0) -> FSL0_M_Data(24 to 31)
din_ready            -> FSL0_M_Write
busy                    -> FSL0_M_Full

You need to enable FSL Interfaces to MicroBlaze with the parameter 
C_FSL_LINKS (set it to 1)
You can write to the fsl interface with the function putfslx, you can read 
more about this function in the document "OS and Libraries Document 
Collection".

Göran

"Ray D." <ray.delvecchio@gmail.com> wrote in message 
news:276dce6d-c9ed-4937-95ea-e3c86ff3656a@d45g2000hsc.googlegroups.com...
> Hey all,
>
> I have a Xilinx Spartan-3E starter board, and I'm implementing a
> MicroBlaze processor on the FPGA.  I would also like to use the LCD
> which is on board, and I have already developed a hardware module that
> takes care of initialization and printing to the LCD.  The interface
> is shown below:
>
> entity LCD_top is
>    Port (
>    clk : in  STD_LOGIC;
>           reset : in  STD_LOGIC;
>
>    din : in STD_LOGIC_VECTOR (7 downto 0);
>    din_ready : in STD_LOGIC;
>    busy : out STD_LOGIC;
>
>           LCD_D : out  STD_LOGIC_VECTOR (11 downto 8);
>           LCD_E : out  STD_LOGIC;
>           LCD_RS : out  STD_LOGIC;
>           LCD_RW : out  STD_LOGIC
>
> );
> end LCD_top;
>
> I really would like to instantiate this module along with the
> processor core.  My question is this - how would I go about
> interfacing this with the MicroBlaze processor internal to the FPGA?
> What I would like to do is define a GPIO port on the processor to
> connect to the din, din_ready and busy lines of the LCD module, but I
> keep getting the following error:
>
> ERROR:MDT - INST:LCD_data_status_10Bit PORT:GPIO_IO
>   CONNECTOR:LCD_data_status_10Bit_GPIO_IO - C:\EDK_Test_LCD
> \system.mhs line 150
>   - connection is not connected to an external port!
>   MPD subproperties IOB_STATE=BUF|REG or THREE_STATE=TRUE require
> that the port
>   be connected directly to an external port.
>
> Is there any way to work around this?  I realize I could just connect
> the LCD to the GPIO directly and write software drivers, but I'm
> trying to avoid that because I already have the hardware module in
> place and working smoothly.  It will also be nice to have this
> separate module so that it does the work of printing to the LCD, and
> the processor itself can stay busy with other more important jobs.
>
> Also, is there an easier way to add another hardware module without
> manually editing the generated VHDL files for the core?  I'm not sure
> if you can do that within Platform Studio.
>
> Any advice would be much appreciated, thanks!
>
> Ray 



Article: 133976
Subject: Re: Change clock domain for FIFO ...
From: "Kappasm" <_NOSPAM_78kappa78_NO_SPAM@virgilio.it>
Date: Mon, 21 Jul 2008 08:56:55 +0200
Links: << >>  << T >>  << A >>
Hi Kenn,

> I'm not sure what your application is, but for DVB-ASI you might also
> want to make sure that you do any PCR restamping, if needed, on the
> appropriate side of the FIFO. If you blindly dump your data into some
> clock-crossing FIFO you'll wind up introducing extra PCR accuracy
> jitter.

It's true, his problem will be solved later, for now is fine as is. Thank.

My problem remains take data from the tuner and place in fifo, without 
problems of any kind.

Regards,

Kappa. 



Article: 133977
Subject: DVI to BT.656
From: akshat <mailtoakshat@gmail.com>
Date: Mon, 21 Jul 2008 00:08:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi All,

Has anyone tried to convert DVI format to BT.656?
Is there any IP or Reference design available for this?


Regards,
Akshat

Article: 133978
Subject: Re: Change clock domain for FIFO ...
From: "Kappasm" <_NOSPAM_78kappa78_NO_SPAM@virgilio.it>
Date: Mon, 21 Jul 2008 09:11:17 +0200
Links: << >>  << T >>  << A >>
Hi Lorenz,

> Well, I'd give it a try and directly connect that clock on the producer 
> (write-) side of the FIFO. Only if that does not work (though I think it 
> will) You should consider sampling the data yourself using a clock with at 
> least 22500000 Hz, but I'd not recommand that, as sampling might really 
> bring You some unexpected results.

I have 27 MHz, Do you think it is enough ?

> Nevertheless if you have to: I'd design some kind of "edge detection" for 
> the input clock (saving the last value and comparing it to the current 
> value) and sampling then whenever you detect an edge.
> You might also want to consider sampling only with falling edge depending 
> on when the data is stable compared to the clock's edges

This code is right ?

[code]
entity parallel_input is
 port (
            reset        : in 
            -- External reste
            clk           : in 
            -- Clock 27 MHz
            clk_tuner : in  std_logic;                                    --  
Clock tuner (depends on Symbol rate)
            din          : in  std_logic_vector (7 downto 0);    -- Parallel 
Transport stream
            sync        : in 
            -- Sync   (1 = Sync / 0 = Data) (0x47) on Transport Stream
            parity       : in 
            -- Parity (1 = Data / 0 = Parity)            on Transport Stream
            dout         : out std_logic_vector (9 downto 0);  -- Output for 
fifo (D/P + Sync + Data)
            vout         : out 
          -- Valid out for WE FIFO
       );
end parallel_input;

architecture Behavioral of parallel_input is

 --
 -- Internal Signal
 --
 signal syncExClock : std_logic := '0';
 signal lastExClock : std_logic := '0';

begin

 -- Capture Clock
 process(reset, clk)
    begin

        if reset = '1' then
            syncExClock <= '0';
            lastExClock <= '0';
           dout <= (others => '0');
       elsif rising_edge(clk) then
           syncExClock <= clk_tuner;
           lastExClock <= syncExClock;
           dout <= parity & sync & din;
       end if;
 end process;

 -- Output
 vout <= syncExClock and not lastExClock;

end Behavioral;
[/code]

Regards,

Kappa. 



Article: 133979
Subject: why holdtime is not considerd for Tclkmax calculation
From: "ekavirsrikanth@gmail.com" <ekavirsrikanth@gmail.com>
Date: Mon, 21 Jul 2008 00:12:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi ALL,

i just wanted to know why hold time is not considered when we are
calculating the Max Frequncy of the sequential design.

we only consider the Setup time while doing the Max freq.... Tclk>
tsetup + tComb Logic + tclk-q delay- tskew.

while calculating the Thold<= Tclk-q + tComblogic + Tskew

Please let me know if i am wrong

regards
srik

Article: 133980
Subject: Re: Change clock domain for FIFO ...
From: Lorenz Kolb <lorenz.kolb@uni-ulm.de>
Date: Mon, 21 Jul 2008 09:53:45 +0200
Links: << >>  << T >>  << A >>
Kappasm wrote:
> Hi Lorenz,
> 
>> Well, I'd give it a try and directly connect that clock on the producer 
>> (write-) side of the FIFO. Only if that does not work (though I think it 
>> will) You should consider sampling the data yourself using a clock with at 
>> least 22500000 Hz, but I'd not recommand that, as sampling might really 
>> bring You some unexpected results.
> 
> I have 27 MHz, Do you think it is enough ?

At least according to the sampling theorem that has to be enough. Though 
you might want to sample the external clock both with rising and falling 
internal clock edge, just to be save.

> 
>> Nevertheless if you have to: I'd design some kind of "edge detection" for 
>> the input clock (saving the last value and comparing it to the current 
>> value) and sampling then whenever you detect an edge.
>> You might also want to consider sampling only with falling edge depending 
>> on when the data is stable compared to the clock's edges
> 
> This code is right ?
>

Assuming you added the syntax errors (insufficient port declarations) on 
purpose ;-) the description is as I had described.
Nevertheless I cannot garantee it will be working, it is just the idea 
that came to my mind to (possibly) solve the issue.

Just to be sure once again:
You have tried connecting the external clock directly to the fifo, 
haven't you?

> 
> Regards,
> 
> Kappa. 
> 
> 

Regards,

Lorenz

Article: 133981
Subject: Re: Change clock domain for FIFO ...
From: "Kappasm" <_NOSPAM_78kappa78_NO_SPAM@virgilio.it>
Date: Mon, 21 Jul 2008 10:18:36 +0200
Links: << >>  << T >>  << A >>

Hi Lorenz Kolb,

> Just to be sure once again:
> You have tried connecting the external clock directly to the fifo, haven't 
> you?

Yes, I connected the clock directly to FIFO.

I have connect a led to empty and full fifo.

On power up the empty LED is on and full LED is off. It's OK.

After a few seconds I active the tuner and the both LEDs light up.

The fifo is never read because is empty.

I have not connected the chipscope to control, but I imagine there are 
problems on integrity of the clock.

Other tests or ideas ?

Thanks.

Regards,

Kappa. 



Article: 133982
Subject: Re: Change clock domain for FIFO ...
From: Lorenz Kolb <lorenz.kolb@uni-ulm.de>
Date: Mon, 21 Jul 2008 10:39:52 +0200
Links: << >>  << T >>  << A >>
Kappasm wrote:
> Hi Lorenz Kolb,
> 
>> Just to be sure once again:
>> You have tried connecting the external clock directly to the fifo, haven't 
>> you?
> 
> Yes, I connected the clock directly to FIFO.
> 
> I have connect a led to empty and full fifo.
> 
> On power up the empty LED is on and full LED is off. It's OK.
> 
> After a few seconds I active the tuner and the both LEDs light up.
> 

So empty and full are both asserted? That's weird and sound rather to be 
a FIFO problem than an interface problem. Do you use some special FIFO 
or just the FIFO mode of the BRAM blocks?
If you use the FIFO mode of the BRAM blocks: have you read the erratas? 
There are quite a lot (especially for asy<nchronous FIFOs).

Do you do a clean 3 slowest clock cycles reset before writing to the 
FIFO? (in case of BRAMblocks in FIFO mode, see e.g. ug070 for details).

> Other tests or ideas ?
> 

Any chance to simulate the system with the models provided by Xilinx? 
and some small testbench for simulating the tuner, maybe that reveals 
why your FIFO shows that strange bevahiour.

> Thanks.
> 
> Regards,
> 
> Kappa. 
> 
> 

Regards,

lorenz

Article: 133983
Subject: Re: Change clock domain for FIFO ...
From: "Kappasm" <_NOSPAM_78kappa78_NO_SPAM@virgilio.it>
Date: Mon, 21 Jul 2008 12:21:19 +0200
Links: << >>  << T >>  << A >>
> So empty and full are both asserted? That's weird and sound rather to be a 
> FIFO problem than an interface problem. Do you use some special FIFO or 
> just the FIFO mode of the BRAM blocks?

Yes, empty and full are both asserted. I use a FIFO based on BRAM blocks 
(Xilinx).

> If you use the FIFO mode of the BRAM blocks: have you read the erratas? 
> There are quite a lot (especially for asy<nchronous FIFOs).

NO. I have not read anything.

You have some links ?

> Do you do a clean 3 slowest clock cycles reset before writing to the FIFO? 
> (in case of BRAMblocks in FIFO mode, see e.g. ug070 for details).

No. I have to wait at least 3 clock cycles before activating WE. Implemento 
this change.

> Any chance to simulate the system with the models provided by Xilinx? and 
> some small testbench for simulating the tuner, maybe that reveals why your 
> FIFO shows that strange bevahiour.

Yes. I have ModelSim XE, even if they are not very good to use it.

If I use my synchronizer, everything works perfectly. The problem occurs 
only without. Clock Tuner direct to Clock (right) FIFO.

Thanks.

Regards,

Kappa.



Article: 133984
Subject: Re: Which FPGA has most ram in a TQFP144 or smaller non-BGA?
From: dowlers <eoindowling@gmail.com>
Date: Mon, 21 Jul 2008 04:53:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
Did you look at the Lattice XP2-8?

http://www.latticesemi.com/products/fpga/xp2


Article: 133985
Subject: Re: why holdtime is not considerd for Tclkmax calculation
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 21 Jul 2008 04:53:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 21, 3:12=A0am, "ekavirsrika...@gmail.com"
<ekavirsrika...@gmail.com> wrote:
> Hi ALL,
>
> i just wanted to know why hold time is not considered when we are
> calculating the Max Frequncy of the sequential design.
>
> we only consider the Setup time while doing the Max freq.... Tclk>
> tsetup + tComb Logic + tclk-q delay- tskew.
>

The short answer is because hold time requirements occur *after* the
clock edge, not *before* (like setup).

A hold time requirement is a requirement to hold the input data to a
flop stable for a period of time after the rising edge of the clock
has occurred.  Where this comes into play is if you have the Q output
of a fast flop feeding into the D input of a flop that has a hold time
requirement greater than 0 ns.  If the minimum Tco is greater than
Thold you have a design issue.

When you're calculating the max frequency your concern is
- What is the slowest delay from Q output to the D input.
- What is the skew between the clock inputs of the two flops in
question.

When calculating the slowest delay, you use Tco (max) because it
contributes to calculating the slowest delay from Q to D (plus the
logic delay, plus the setup time).

> while calculating the Thold<=3D Tclk-q + tComblogic + Tskew
>

No.  Th < Tco(min) + tComblogic(min) + Tskew(max)

The race is between the Q output and its logic as compared to the
clock skew to insure that it meets the requirement.

That's also why, if you do happen to have a hold time design problem,
the frequency of failure will not change as you speed up or slow down
the clock.

Kevin Jennings

Article: 133986
Subject: Re: Change clock domain for FIFO ...
From: Lorenz Kolb <lorenz.kolb@uni-ulm.de>
Date: Mon, 21 Jul 2008 14:11:31 +0200
Links: << >>  << T >>  << A >>
Kappasm wrote:
>> So empty and full are both asserted? That's weird and sound rather to be a 
>> FIFO problem than an interface problem. Do you use some special FIFO or 
>> just the FIFO mode of the BRAM blocks?
> 
> Yes, empty and full are both asserted. I use a FIFO based on BRAM blocks 
> (Xilinx).
> 
>> If you use the FIFO mode of the BRAM blocks: have you read the erratas? 
>> There are quite a lot (especially for asy<nchronous FIFOs).
> 
> NO. I have not read anything.
> 
> You have some links ?
> 

UG070 (you mentioned Virtex-4 previously) has the most common erratas 
and the workarounds.

>> Do you do a clean 3 slowest clock cycles reset before writing to the FIFO? 
>> (in case of BRAMblocks in FIFO mode, see e.g. ug070 for details).
> 
> No. I have to wait at least 3 clock cycles before activating WE. Implemento 
> this change.
> 

Only for the initial reset of the FIFO16 blocks.

>> Any chance to simulate the system with the models provided by Xilinx? and 
>> some small testbench for simulating the tuner, maybe that reveals why your 
>> FIFO shows that strange bevahiour.
> 
> Yes. I have ModelSim XE, even if they are not very good to use it.
> 
> If I use my synchronizer, everything works perfectly. The problem occurs 
> only without. Clock Tuner direct to Clock (right) FIFO.
> 

So the synchronizer works fine? then take that one and as long as you 
are sampling on the falling edge of your tuner's clock I suppose there 
is more than enough "room" left for sampling exact enough that there are 
no sampling errors.

> Thanks.
> 
> Regards,
> 
> Kappa.
> 
> 

Regards,

Lorenz

Article: 133987
Subject: Re: Change clock domain for FIFO ...
From: Lorenz Kolb <lorenz.kolb@uni-ulm.de>
Date: Mon, 21 Jul 2008 14:24:21 +0200
Links: << >>  << T >>  << A >>
Lorenz Kolb wrote:

>>
>> You have some links ?
>>
> 
> UG070 (you mentioned Virtex-4 previously) has the most common erratas 
> and the workarounds.

http://www.xilinx.com/support/answers/22462.htm

Article: 133988
Subject: Re: Change clock domain for FIFO ...
From: "Kappasm" <_NOSPAM_78kappa78_NO_SPAM@virgilio.it>
Date: Mon, 21 Jul 2008 14:59:21 +0200
Links: << >>  << T >>  << A >>
> UG070 (you mentioned Virtex-4 previously) has the most common erratas and 
> the workarounds.

Thanks ...

> Only for the initial reset of the FIFO16 blocks.

OK.

> So the synchronizer works fine? then take that one and as long as you are 
> sampling on the falling edge of your tuner's clock I suppose there is more 
> than enough "room" left for sampling exact enough that there are no 
> sampling errors.

Yes, works fine. We do know further developments.

Thanks.

 Regards,

Kappa.



Article: 133989
Subject: audio serial port i2s
From: wojjed@gmail.com
Date: Mon, 21 Jul 2008 06:11:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi

I was thinking about interfacing PCM4204 audio codec by TI with Xilinx
FPGA XC3S200. Audio serial port I2S needs 3 lines - two clock lines
BCK and LRCK and one data line. I thought it would be good to have
ability to change state of PCM codec between master and slave. In
master mode codec generates both LRCK and BCK clock lines, which are
connected tp my FPGA. In slave mode i need to generate that signals.
Now question - having clock master connected to FPGA (GCLKx Pin) with
12.288 Mhz frequency - can i divide that clock by 256 to have my LRCK
= 44100 Mhz ?  Another question is  should i use GCLK pins as input/
output for that clocks or it doesn't matter ?

best regards
wj

Article: 133990
Subject: Re: audio serial port i2s
From: "RCIngham" <robert.ingham@gmail.com>
Date: Mon, 21 Jul 2008 09:13:22 -0500
Links: << >>  << T >>  << A >>
>Hi
>
>I was thinking about interfacing PCM4204 audio codec by TI with Xilinx
>FPGA XC3S200. Audio serial port I2S needs 3 lines - two clock lines
>BCK and LRCK and one data line. I thought it would be good to have
>ability to change state of PCM codec between master and slave. In
>master mode codec generates both LRCK and BCK clock lines, which are
>connected tp my FPGA. In slave mode i need to generate that signals.
>Now question - having clock master connected to FPGA (GCLKx Pin) with
>12.288 Mhz frequency - can i divide that clock by 256 to have my LRCK
>= 44100 Mhz ?  Another question is  should i use GCLK pins as input/
>output for that clocks or it doesn't matter ?
>
>best regards
>wj
>

My calculator says that 12.288 MHz / 44100 Hz = 278.63946, which suggests
that you need a different master clock frequency, or you will have
jitter-related problems.

Whatever you do about the above, don't use GCLK pins. When LRCK is an
input, treat it as a data signal, sample it with the system clock, and
detect the edges as per normal good practice.



Article: 133991
Subject: Re: audio serial port i2s
From: rickman <gnuarm@gmail.com>
Date: Mon, 21 Jul 2008 07:51:07 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 21, 9:11 am, woj...@gmail.com wrote:
> Hi
>
> I was thinking about interfacing PCM4204 audio codec by TI with Xilinx
> FPGA XC3S200. Audio serial port I2S needs 3 lines - two clock lines
> BCK and LRCK and one data line. I thought it would be good to have
> ability to change state of PCM codec between master and slave. In
> master mode codec generates both LRCK and BCK clock lines, which are
> connected tp my FPGA. In slave mode i need to generate that signals.
> Now question - having clock master connected to FPGA (GCLKx Pin) with
> 12.288 Mhz frequency - can i divide that clock by 256 to have my LRCK
> = 44100 Mhz ?  Another question is  should i use GCLK pins as input/
> output for that clocks or it doesn't matter ?
>
> best regards
> wj

I can't answer your questions since they depend on the CODEC more than
anything.  But I just did a design with an AKM codec and used it in
slave mode generating the clocks in the FPGA.  It worked perfectly the
first time I tried it!  No debugging necessary.  I also connected all
of the control signals from the CODEC to the FPGA, but hold them in a
constant state.  This allows me to change the sample rate for other
apps.

I am pretty sure the GCLK pin can be used as a general I/O pin, so you
can output the clock as well as input it.  But the 12.288 clock won't
come from your CODEC will it?  Does this CODEC have a crystal osc in
it?  I think the 12.288 MHz clock is always an input to the CODEC.

BTW, the CODEC I am using is the AK4556 in a small 20 pin TSSOP.  Not
hard to solder, is only 6.5 x 6.5 mm, under $3, less than 100 mW and
samples from 8 to 192 kHz.  All analog I/O is single ended.

Rick

Article: 133992
Subject: Re: audio serial port i2s
From: cs_posting@hotmail.com
Date: Mon, 21 Jul 2008 07:54:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 21, 10:13 am, "RCIngham" <robert.ing...@gmail.com> wrote:

> My calculator says that 12.288 MHz / 44100 Hz = 278.63946, which suggests
> that you need a different master clock frequency, or you will have
> jitter-related problems.

12.288 MHz is very typical, because dividing by 256 gives 48 Ksps
which is the typical digital audio sample rate when compatibility with
a CD is not required.  256 also has a lot of power of two factors,
making it possible to have a 32fs or whatever bit clock.

Maybe the OP can run the design at 48 Ksps?

Article: 133993
Subject: Re: audio serial port i2s
From: wojjed@gmail.com
Date: Mon, 21 Jul 2008 08:06:10 -0700 (PDT)
Links: << >>  << T >>  << A >>
> My calculator says that 12.288 MHz / 44100 Hz = 278.63946, which suggests
> that you need a different master clock frequency, or you will have
> jitter-related problems.


Are You sure with that ? Most clock diveders work as a counters and
when counter overflowes, output changes state. So if I use 12.288 as
main clock and count from 1 to 256 i get output changed with 44100 Hz.
Or maybe i made mistake somewhere...






Article: 133994
Subject: Strange behaviour with Xilkernel
From: pperogil@gmail.com
Date: Mon, 21 Jul 2008 08:56:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,

I'm doing some performance tests with multi-threaded xilkernel
applications and I always get erroneous times in programs where
context switches occurs continuously. I have written a trivial
application that shows the problem:

Two threads running without communication between them. Each one
simply iterates N times and in each loop makes a yield() call. This
ensures one context switch per loop and thread (both have the same
priority and the policy is SCHED_PRIO). Now, each M iterations, I
track the elapsed kernel ticks and print them on screen. Both
xilkernel and the main application are optimized (-O2) and each
xilkernel tick is set to 10 milliseconds.

thread body
===========

#define N    1000000
#define M    1000

for (i=0; i<N; i++) {

  yield();

  if (!(i % M)) {
    time = xget_clock_ticks();
    xil_printf("Elapsed time: %d msec\n", time * 10);
}

===========

Results indicate that the times printed by the application are always
lesser than the times elapsed in reality (you can measure the real
elapsed time, for example, with the Windows' clock or with a
timekeeper). I mean if the program really takes about 50 seconds to
finish, I get from application about 24 seconds. This is impossible.

But, if for example, I change yield() for sleep(1), results now
corresponds with the real elapsed time. Moreover, if I do yield() each
X iterations (testing progressively with a bigger value of X: 10, 100,
1000...1000000), the results printed on screen fit more and more to
the real elapsed times.

Can anyone explain me what is happening?, Is it a xilkernel bug?

Many thanks for your help.
Paco

Article: 133995
Subject: Strange behaviour with Xilkernel
From: pperogil@gmail.com
Date: Mon, 21 Jul 2008 09:03:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hi all,

I'm doing some performance tests with multi-threaded xilkernel
applications and I always get erroneous times in programs where
context switches occurs continuously. I have written a trivial
application that shows the problem:

Two threads running without communication between them. Each one
simply iterates N times and in each loop makes a yield() call. It
ensures one context switch per loop and thread (both have the same
priority and the policy is SCHED_PRIO). Now, each M iterations, I
track the elapsed kernel ticks and print them on screen. Both
xilkernel and the main application are optimized (-O2) and each
xilkernel tick is set to 10 milliseconds.

thread body
===========

#define N    1000000
#define M    1000

for (i=0; i<N; i++) {

  yield();

  if (!(i % M)) {
    time = xget_clock_ticks();
    xil_printf("Elapsed time: %d msec\n", time * 10);
}

===========

Results indicate that the times printed by the application are always
lesser than the times elapsed in reality (you can measure the real
elapsed time, for example, with the Windows' clock or with a
timekeeper). I mean if the program really takes about 50 seconds to
finish, I get from application about 24 seconds. This is impossible.

For example, If I change yield() for sleep(1), results now corresponds
with the real elapsed time. Moreover, if I do yield() each X
iterations (testing progressively with a bigger value of X: 10, 100,
1000...1000000), the results printed on screen fit more and more to
the real elapsed times.

Can anyone explain me what is happening?, Is it a xilkernel bug?

Many thanks for your help.
Paco

Article: 133996
Subject: Re: Additional Hardware Module with Xilinx MicroBlaze Processor
From: "Ray D." <ray.delvecchio@gmail.com>
Date: Mon, 21 Jul 2008 09:14:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 21, 2:36 am, "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote:
> Hi,
>
> Depending a little on how your busy signals work, you might just hook up
> your module to the FSL interface on MicroBlaze.
> Your busy signal needs be high when it can't accept a new word even when
> there is no attempt to write to the module.
> MicroBlaze will also just do one cycle write so your module needs to acce=
pt
> a new word in one clock cycle when busy is low.
>
> Connect:
> din(7 downto 0) -> FSL0_M_Data(24 to 31)
> din_ready            -> FSL0_M_Write
> busy                    -> FSL0_M_Full
>
> You need to enable FSL Interfaces to MicroBlaze with the parameter
> C_FSL_LINKS (set it to 1)
> You can write to the fsl interface with the function putfslx, you can rea=
d
> more about this function in the document "OS and Libraries Document
> Collection".
>
> G=F6ran
>
> "Ray D." <ray.delvecc...@gmail.com> wrote in message
>
> news:276dce6d-c9ed-4937-95ea-e3c86ff3656a@d45g2000hsc.googlegroups.com...
>
> > Hey all,
>
> > I have a Xilinx Spartan-3E starter board, and I'm implementing a
> > MicroBlaze processor on the FPGA.  I would also like to use the LCD
> > which is on board, and I have already developed a hardware module that
> > takes care of initialization and printing to the LCD.  The interface
> > is shown below:
>
> > entity LCD_top is
> >    Port (
> >    clk : in  STD_LOGIC;
> >           reset : in  STD_LOGIC;
>
> >    din : in STD_LOGIC_VECTOR (7 downto 0);
> >    din_ready : in STD_LOGIC;
> >    busy : out STD_LOGIC;
>
> >           LCD_D : out  STD_LOGIC_VECTOR (11 downto 8);
> >           LCD_E : out  STD_LOGIC;
> >           LCD_RS : out  STD_LOGIC;
> >           LCD_RW : out  STD_LOGIC
>
> > );
> > end LCD_top;
>
> > I really would like to instantiate this module along with the
> > processor core.  My question is this - how would I go about
> > interfacing this with the MicroBlaze processor internal to the FPGA?
> > What I would like to do is define a GPIO port on the processor to
> > connect to the din, din_ready and busy lines of the LCD module, but I
> > keep getting the following error:
>
> > ERROR:MDT - INST:LCD_data_status_10Bit PORT:GPIO_IO
> >   CONNECTOR:LCD_data_status_10Bit_GPIO_IO - C:\EDK_Test_LCD
> > \system.mhs line 150
> >   - connection is not connected to an external port!
> >   MPD subproperties IOB_STATE=3DBUF|REG or THREE_STATE=3DTRUE require
> > that the port
> >   be connected directly to an external port.
>
> > Is there any way to work around this?  I realize I could just connect
> > the LCD to the GPIO directly and write software drivers, but I'm
> > trying to avoid that because I already have the hardware module in
> > place and working smoothly.  It will also be nice to have this
> > separate module so that it does the work of printing to the LCD, and
> > the processor itself can stay busy with other more important jobs.
>
> > Also, is there an easier way to add another hardware module without
> > manually editing the generated VHDL files for the core?  I'm not sure
> > if you can do that within Platform Studio.
>
> > Any advice would be much appreciated, thanks!
>
> > Ray

That is how the module works so I'll have to try some of these
options!  The busy signal is set high the entire time data is being
written to the LCD.  Originally I had a module "program.vhd" that
controlled the LCD module along with a keyboard module that we we had
in place for user input.  Within program.vhd, I implement a state
machine and check if the busy signal is high before writing to the
LCD.  If busy =3D 0, then I set din_ready high and set the 8-bits of
data.  This is buffered within the LCD module and you only need to
hold din_ready for a single cycle to write to the LCD.  The LCD is
connected over a 4-bit interface to the FPGA and this is taken care of
within the LCD module.  When the writing operation begins busy is set
to '1' until complete.

Ray

Article: 133997
Subject: Re: audio serial port i2s
From: wojjed@gmail.com
Date: Mon, 21 Jul 2008 10:17:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 21 Lip, 17:06, woj...@gmail.com wrote:
> > My calculator says that 12.288 MHz / 44100 Hz = 278.63946, which suggests
> > that you need a different master clock frequency, or you will have
> > jitter-related problems.
>
> Are You sure with that ? Most clock diveders work as a counters and
> when counter overflowes, output changes state. So if I use 12.288 as
> main clock and count from 1 to 256 i get output changed with 44100 Hz.
> Or maybe i made mistake somewhere...

My mistake, i mean of course 48 kHz

Article: 133998
Subject: Re: audio serial port i2s
From: "M.Randelzhofer" <techseller@gmx.de>
Date: Mon, 21 Jul 2008 19:40:44 +0200
Links: << >>  << T >>  << A >>
<wojjed@gmail.com> schrieb im Newsbeitrag 
news:56f313a4-cf72-4d40-b478-876b1d7f709e@w7g2000hsa.googlegroups.com...
> Hi
>
> I was thinking about interfacing PCM4204 audio codec by TI with Xilinx
> FPGA XC3S200. Audio serial port I2S needs 3 lines - two clock lines
> BCK and LRCK and one data line. I thought it would be good to have
> ability to change state of PCM codec between master and slave. In
> master mode codec generates both LRCK and BCK clock lines, which are
> connected tp my FPGA. In slave mode i need to generate that signals.
> Now question - having clock master connected to FPGA (GCLKx Pin) with
> 12.288 Mhz frequency - can i divide that clock by 256 to have my LRCK
> = 44100 Mhz ?  Another question is  should i use GCLK pins as input/
> output for that clocks or it doesn't matter ?
>
> best regards
> wj

Yes you can divide your 12.288MHz clock for LRCLK (WS) and BITCLK (SCK).
A simple sync up counter generates an adequate I2S phase relationship.
see:
http://www.nxp.com/acrobat_download/various/I2SBUS.pdf

Use GCLK for the 12.288MHz master clock input, all other generated signals 
can be normal I/Os.

Check if thee is a timing contraint between the ADC system clock (here 
12.288MHz) and the lower ADC clocks.

A master clock of 2x or 4x 12.288MHz (49.152MHz) allows equal clock to 
output times for all ADC signals.

MIKE

-- 
www.oho-elektronik.de
OHO-Elektronik
Michael Randelzhofer
FPGA und CPLD Mini Module
Klein aber oho !
Kontakt:
Tel: 08131 339230
mr@oho-elektronik.de
Usst.ID: DE130097310 



Article: 133999
Subject: Re: audio serial port i2s
From: rickman <gnuarm@gmail.com>
Date: Mon, 21 Jul 2008 10:45:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Jul 21, 11:06 am, woj...@gmail.com wrote:
> > My calculator says that 12.288 MHz / 44100 Hz = 278.63946, which suggests
> > that you need a different master clock frequency, or you will have
> > jitter-related problems.
>
> Are You sure with that ? Most clock diveders work as a counters and
> when counter overflowes, output changes state. So if I use 12.288 as
> main clock and count from 1 to 256 i get output changed with 44100 Hz.
> Or maybe i made mistake somewhere...

Yes, you made a mistake.  Dividing 12288 kHz by 256 you get 48 kHz.

I don't remember for sure what the basis of 44100 Hz was, but I think
it has to do with being compatible with TV scan rates.  It is
divisible by both 50 Hz and 60 Hz.  But then so is 48,000 Hz.  44100
has as divisors, a pair each of 2, 3, 5 and 7.  I'm not sure why this
is, but the sevens make it incompatible with most standard clock rates
for audio.  The lowest clock rate I can find that is a multiple of
both 48 kHz and 44.1 kHz and above 10 MHz (to run sigma-delta
converters) is 14.112 MHz.  But this gives you some real oddball
divisor values that I don't think CODECs commonly support when using
48 kHz sample rate.

Rick



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