25-11-2018, 02:25 PM
I don't think that's noise. Just a less than perfect analogue filter. Should not cause any problems.
www.borinsky.co.uk Jeffrey Borinsky www.becg.tv
FPGA System A modulator
|
25-11-2018, 02:25 PM
I don't think that's noise. Just a less than perfect analogue filter. Should not cause any problems.
www.borinsky.co.uk Jeffrey Borinsky www.becg.tv
25-11-2018, 02:35 PM
Hi Frank.
I agree with Jeffrey, I'm sure a little filtering will be the answer, I've seen this on some of the little transmitters I've made up, totally goes when properly filtered, can't see it being an issue anyway.
Cheers.
Trevor MM0KJJ. Member of, RSGB, GQRP, WACRAL, K&LARC.
25-11-2018, 06:22 PM
It's actually quite difficult to do really good filtering. Depends heavily on the ratio sampling frequency to highest required output. If you've got 8x available (say 360MHz for channel B1) then the filter is dead easy. If you've got 4x (180MHz) then it's not too bad but a simple filter will start to show irregularities. These probably won't matter in terms of practical performance. As you come down from 4x towards the Nyquist limit of 2x it just gets worse. A lot worse. Frank is working around 4x so I'm not surprised. I don't think it's worth improving the filter at this stage. What you win on frequency response you usually lose on group delay or phase response.
www.borinsky.co.uk Jeffrey Borinsky www.becg.tv
25-11-2018, 06:51 PM
Hi Jeffrey and Trevor
That's reassuring I was getting a bit bogged down with that. Hi Stephen I have not got anything worth naming yet good suggestions though. But I think I would need to do something with the spelling first Frank
25-11-2018, 07:06 PM
Frank, what sort of scope do you have? Unless it's 200MHz+ bandwidth it will be telling you possibly significant lies about the waveform. If it's less than 100MHz BW it will be potentially telling big lies.
I'm not familiar with the Altera tools but at the clock speeds you're using it's essential to use them to specify clock speeds. So for the older ISE Xilinx tools for a 200MHz clock I'd put the following in the UCF file: NET "myclock" TNM_NET = thisfastclock; TIMESPEC TS_thisfastclock = PERIOD "myclock" 5ns HIGH 50%; The tools would then try to ensure that anything working with that clock will meet the timing requirements. They will also report paths where the requirements are not met. To meet those sorts of speeds you need maximum pipelining. So multipliers will need internal registers, arithmetic and other logic must have a register after just about every operation. Unless you're going to fill up the device with a lot of logic running at 200MHz you shouldn't be in lunatic land. I run the fairly old Spartan 3 series devices witha lot of stuff running at 148.5MHz. As the device fills up it's tight but manageable. Not into head banging yet.
www.borinsky.co.uk Jeffrey Borinsky www.becg.tv
25-11-2018, 07:47 PM
Hi Jeffrey
I am using a Tektronix 465B 100 MHz scope. I believe that the Altera equivalent of the UCF file is the SDC (Synopsys Design Constraints) file. I wrote one out earlier in the project but I have chopped and changed things a lot since then so it requires updating/rewriting which I have just started to do. I have pipelined the multipliers and have kept combination logic to an absolute minimum. It may benefit from some extra registers I will look into that. Frank
25-11-2018, 09:42 PM
Remember that registers are essentially free in FPGAs. I've not yet done a design which used more registers than logic cells.
For example, if you're adding 3 signals, if you want high speed never write: process (CK) begin if rising_edge(CK) then SUM <= A+B+C; end if; --CK end process; This would cascade a pair of adders, introducing delay. Much better to write: process (CK) begin if rising_edge(CK) then PARTSUM <= A+B; DELAYED_C <= C; SUM <= PARTSUM+DELAYED_C; end if; --CK end process; There is an extra pipeline delay of 1 clock cycle but in most cases this doesn't matter. At the 180MHz or so that you're working, it's absolutely essential to use timing constraints in the SDC file.
www.borinsky.co.uk Jeffrey Borinsky www.becg.tv
25-11-2018, 11:19 PM
Hi Jeffrey
I would have never known that about how adders can cascade. The tool for generating the SDC file is good but is big and takes a while to navigate ones way around it when your not used to it. The SDC file can be wrote manually but there is a better chance of getting it right by using the tool. Frank
26-11-2018, 07:01 AM
Another example of how to minimise logic delays, this time a range limiter.
if A > MAXVALUE then B <= MAXVALUE; elsif A < MINVALUE then B <= MINVALUE; else A < B; end if; Nice simple code but it's got to do 2 comparisons and some extra logic in 1 clock cycle. So let's pipeline it. TOOHIGH and TOOLOW are boolean: TOOHIGH <= (A>MAXVALUE); TOOLOW <= (A< MINVALUE); A1 <= A; -- Pipeline delay so that data matches TOOHIGH and TOOLOW if TOOHIGH then A1 <= MAXVALUE elsif TOOLOW then A! <= MINVALUE; else B <= A1; endif; This separates the comparisons and the logic. I can't estimate the speed gain but it will matter at 180MHz. It won't matter at 60MHz. I know what you mean about generating the SDC. In the older Xilinx ISE tools the UCF is easy enough to write by hand though there are tools available to help. In the newer VIvado tools the constraints such as pinout and timing are in XDC files. These have a more complex syntax than UCF so you tend to use the tools. In practice I've done the initial work using the tools, then edited by hand. As projects get bigger it's useful to have multiple constraints files. At a minimum one for pinout and pin properties, another for timing.
www.borinsky.co.uk Jeffrey Borinsky www.becg.tv
|
Users browsing this thread: |
1 Guest(s) |