Thermometer to binary encoder

Hello,

I needed help in writing a Verilog code for a thermometer to binary encoder for a TDC.

Anything from a flow chart to actual code would be of help.

Popular way in ASIC flash converters is to simple use ROM followed by 1-out-of-n encoder.

thermcod|1-of-n | ROM data
0000000 0000000 000
0000001 0000001 001
0000011 0000010 010
0000111 0000100 011
0001111 0001000 100
0011111 0010000 101
0111111 0100000 110
1111111 1000000 111

axcdd said:

Popular way in ASIC flash converters is to simple use ROM followed by 1-out-of-n encoder.

thermcod|1-of-n | ROM data
0000000 0000000 000
0000001 0000001 001
0000011 0000010 010
0000111 0000100 011
0001111 0001000 100
0011111 0010000 101
0111111 0100000 110
1111111 1000000 111

Click to expand...

Used that and it came out pretty nicely, with a bubble error correction involved too.

However, I now need help in creating delays in verilog so that I can have a high time resolution between clock cycles.

Jetach said:

Used that and it came out pretty nicely, with a bubble error correction involved too.

Click to expand...

Just out of curiosity, how many bits wide was your thermometer code input? That, and what kind of throughput did you get? As in number of decoded thermometer codes per second, that sort of thing.

mrflibble said:

Just out of curiosity, how many bits wide was your thermometer code input? That, and what kind of throughput did you get? As in number of decoded thermometer codes per second, that sort of thing.

Click to expand...

I need to make 8-bits Therm to 3 bits binary. Don't know how to make the truth table for this unless there is a carry.

And I haven't been able to test out the throughput as of yet.

Ah okay. I asked because you wanted to use it for a TDC, and though naaaah he's probably using more than 8 taps. Just be sure to put your decoder through some testbenches.

mrflibble said:

Ah okay. I asked because you wanted to use it for a TDC, and though naaaah he's probably using more than 8 taps. Just be sure to put your decoder through some testbenches.

Click to expand...

Ha I ran a few functions through it to see if it would function, but I haven't used it running a clock or counter to see the efficiency.

And I am using it for a TDC, but the subject can be a bit overwhelming as I've still got two years of my undergrad left and am working on this as an intern.

Building an fpga based TDC can be fun yes. What is your target resolution? Also, if it's going to be a large TDC you'll probably want to limit the bubble tolerant part to the head (or tail, depending) as opposed to the entire thing. Mmmh, now that I think about it that probably also depends on your requirements. So, what resolution and what repetition rate are you going for?

mrflibble said:

Building an fpga based TDC can be fun yes. What is your target resolution? Also, if it's going to be a large TDC you'll probably want to limit the bubble tolerant part to the head (or tail, depending) as opposed to the entire thing. Mmmh, now that I think about it that probably also depends on your requirements. So, what resolution and what repetition rate are you going for?

Click to expand...

I am going for around 10 ps.

Not too sure about the repetition rate, but it will be used in an imaging system so quite a bit from what I would assume.

On what fpga? And 10 ps what? resolution? 1 sigma error? 4958734856345 sigmas?

Repetition rate will mainly dictate if you have to get clever, or if you can get away with being a lazy person.

And what is quite a bit? 200 MHz repetition rate on current generation fpga's is "quite a bit" IMO. If it gets to 1 MHz or below it's boring, and anything in between might be interesting. ;-)

mrflibble said:

On what fpga? And 10 ps what? resolution? 1 sigma error? 4958734856345 sigmas?

Repetition rate will mainly dictate if you have to get clever, or if you can get away with being a lazy person.

And what is quite a bit? 200 MHz repetition rate on current generation fpga's is "quite a bit" IMO. If it gets to 1 MHz or below it's boring, and anything in between might be interesting. ;-)

Click to expand...

Yes, a ten ps resolution. I've been reading a couple research papers such as

https://lss.fnal.gov/archive/2009/conf/fermilab-conf-09-275-e.pdf

and a few others by the same researcher.

It would be run around 100-200MHz.

I'm not clear on how the sigma errors work, if you could explain that would help.

That is sigma as in standard deviation.

And have fun with that wave union paper and it's amusing lack of useful implementation details. For me it was a good source of some inspiration, but that was about it. Even should you decide to fully implement what they used, the paper is not too much help (IMO). Actually that is my pet peeve #1 with those sorts of paper, the absolute lack of any details. That's probably a good thing if you want a grant for the next useless detailless paper, but for those of us that like to replicate findings it's ... suboptimal.

And 100 MHz repetition rate (not boring old 100 MHz sampling rate) should be interesting, since that will force you to do some thinking. XD Well, assuming the TDC is longer than 8 taps obviously.

mrflibble said:

That is sigma as in standard deviation.

And have fun with that wave union paper and it's amusing lack of useful implementation details. For me it was a good source of some inspiration, but that was about it. Even should you decide to fully implement what they used, the paper is not too much help (IMO). Actually that is my pet peeve #1 with those sorts of paper, the absolute lack of any details. That's probably a good thing if you want a grant for the next useless detailless paper, but for those of us that like to replicate findings it's ... suboptimal.

And 100 MHz repetition rate (not boring old 100 MHz sampling rate) should be interesting, since that will force you to do some thinking. XD Well, assuming the TDC is longer than 8 taps obviously.

Click to expand...

I use a lot of the references at the bottom of the research papers, but I agree in the lack of details when it comes to the actual design.

Would you have any resources for that? An actual implementation, not just data found from their implementation.

I've been going on a hunt just looking at multiple references listed at the bottom, but it has led me nowhere.

I found one really solid paper, but it was based for ASIC.

- - - Updated - - -

mrflibble said:

That is sigma as in standard deviation.

And have fun with that wave union paper and it's amusing lack of useful implementation details. For me it was a good source of some inspiration, but that was about it. Even should you decide to fully implement what they used, the paper is not too much help (IMO). Actually that is my pet peeve #1 with those sorts of paper, the absolute lack of any details. That's probably a good thing if you want a grant for the next useless detailless paper, but for those of us that like to replicate findings it's ... suboptimal.

And 100 MHz repetition rate (not boring old 100 MHz sampling rate) should be interesting, since that will force you to do some thinking. XD Well, assuming the TDC is longer than 8 taps obviously.

Click to expand...

I use a lot of the references at the bottom of the research papers, but I agree in the lack of details when it comes to the actual design.

Would you have any resources for that? An actual implementation, not just data found from their implementation.

I've been going on a hunt just looking at multiple references listed at the bottom, but it has led me nowhere.

I found one really solid paper, but it was based for ASIC.

- - - Updated - - -

mrflibble said:

That is sigma as in standard deviation.

And have fun with that wave union paper and it's amusing lack of useful implementation details. For me it was a good source of some inspiration, but that was about it. Even should you decide to fully implement what they used, the paper is not too much help (IMO). Actually that is my pet peeve #1 with those sorts of paper, the absolute lack of any details. That's probably a good thing if you want a grant for the next useless detailless paper, but for those of us that like to replicate findings it's ... suboptimal.

And 100 MHz repetition rate (not boring old 100 MHz sampling rate) should be interesting, since that will force you to do some thinking. XD Well, assuming the TDC is longer than 8 taps obviously.

Click to expand...

I use a lot of the references at the bottom of the research papers, but I agree in the lack of details when it comes to the actual design.

Would you have any resources for that? An actual implementation, not just data found from their implementation.

I've been going on a hunt just looking at multiple references listed at the bottom, but it has led me nowhere.

I found one really solid paper, but it was based for ASIC.

I'd have to dive into my notes... What have you managed to find so far?

Maybe u can try to implement fat tree encoder on FPGA. Im curious about the results ;]

Any progress?

I managed to write out the encoder and a coarse counter.

However, at this point I am having difficulty with the delay carry chain.

Rather than having forced delays such as: wait for 10 ns;

I want to have a true code, hardware implementation delays, but when I run Isim it runs everything immediately when I try to run two adders.

entity DelayLine is
Port ( A,B : in STD_LOGIC_VECTOR (31 downto 0);
Cin : in STD_LOGIC;
Sum : out STD_LOGIC_VECTOR (31 downto 0);
Cout ut STD_LOGIC);
end DelayLine;

architecture Behavioral of DelayLine is
COMPONENT FullAdder
PORT(
Ax : IN std_logic;
Bx : IN std_logic;
Cin : IN std_logic;
Sx : OUT std_logic;
Cout:OUT std_logic );
END COMPONENT;

Signal Carry: STD_LOGIC_VECTOR (32 downto 0);
begin
Carry(0) <= Cin;

Adder32:
for i in 0 to 31 generate
FAx: FullAdder PORT MAP(
Ax => A(i),
Bx => B(i),
Cin => Carry(i),
Sx => Sum(i),
Cout => Carry(i+1));
end generate;

Cout <= Carry(32);
end Behavioral;

I realize this is marked as 'solved', but since this is being implemented in an FPGA, perhaps the most quick (and most simple) implementation would be a look up table. If you are only doing 8-bits for the decoder, then I think that could fit quite nicely in one or a few LUT blocks on the FPGA.

Now if you are doing a large bit-count decoder, then something fancy might be advantageous. But, for only 8-bits, I think any decoding scheme would be best handled by a LUT.

Argue with me if I'm wrong here.

You're not wrong, but a solution for 8 bits is fairly trivial. How about if it's lets say in the 128-256 bit range?

As an aside, I suspect that as long as it fits a certain magic maximum number of logic levels the synthesizer will in fact use a bunch of LUTs.

I will try out a look up table. I am just doing a very simple TDC and will make it have more bits in a later stage.

I also need to make sure that the TDC is able to calibrate according to temperature and voltage, and I have read things about a wave union launcher to be able to maintain that.

- - - Updated - - -

Also, another thought I had is would it be possible to use an MMCM to create a faster clock cycle and run off that? Or would it not be able to generate a fast enough clock for the resolution I want?