Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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! > > RayArticle: 133976
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
Hi All, Has anyone tried to convert DVI format to BT.656? Is there any IP or Reference design available for this? Regards, AkshatArticle: 133978
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: 133979Hi 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 srikArticle: 133980
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, LorenzArticle: 133981
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
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, lorenzArticle: 133983
> 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
Did you look at the Lattice XP2-8? http://www.latticesemi.com/products/fpga/xp2Article: 133985
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 JenningsArticle: 133986
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, LorenzArticle: 133987
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.htmArticle: 133988
> 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
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 wjArticle: 133990
>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
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. RickArticle: 133992
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
> 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
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
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: 133996On 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. RayArticle: 133997
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 kHzArticle: 133998
<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: DE130097310Article: 133999
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:
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